When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository. This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning. Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9? Would people mind defaulting the revision to 1? I don't know how this would be rolled out. It would cause a massive upgrade. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
Have you tried using revision -1 (negative 1) for your private ports? On 9 Oct 2006, at 23:23, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
Would people mind defaulting the revision to 1?
I don't know how this would be rolled out. It would cause a massive upgrade.
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On 10/9/06, Blair Zajac <blair@orcaware.com> wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
I would very much like to see this happen - and while we're at it, change it so that pre-release information is encoded in the revision field (i.e. lame 3.97b2 -> lame 3.97-0.b2.1), making automated upgrade less painful to deal with (3.97-1, the first stable 3.97 release, would be seen as newer than 3.97-0.b2.1 but not 3.97b2-1) -- Michel Salim http://www.cs.indiana.edu/~msalim http://the-dubois-papers.blogspot.com/
Good idea. No, I haven't tried. Does it work? Regards, Blair Randall Wood wrote:
Have you tried using revision -1 (negative 1) for your private ports?
On 9 Oct 2006, at 23:23, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
Would people mind defaulting the revision to 1?
I don't know how this would be rolled out. It would cause a massive upgrade.
Regards, Blair
--Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com
"The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
On Oct 10, 2006, at 10:46 AM, Blair Zajac wrote:
Good idea. No, I haven't tried. Does it work?
I'm skeptical of negative revision numbers, due in part to parsing of the version string... I think negative numbers might confuse us, due to similarity with options and variant names. James
Regards, Blair
Randall Wood wrote:
Have you tried using revision -1 (negative 1) for your private ports? On 9 Oct 2006, at 23:23, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
Would people mind defaulting the revision to 1?
I don't know how this would be rolled out. It would cause a massive upgrade.
Regards, Blair
--Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Revisions should be a monotonically increasing serial number (think SVN revisions) indicating the revision of the Portfile. The purpose of the revision is to provide a unique primary key for every portfile: {name, version, revision}. - Kevin On Oct 10, 2006, at 11:12 AM, James Berry wrote:
On Oct 10, 2006, at 10:46 AM, Blair Zajac wrote:
Good idea. No, I haven't tried. Does it work?
I'm skeptical of negative revision numbers, due in part to parsing of the version string... I think negative numbers might confuse us, due to similarity with options and variant names.
James
Regards, Blair
Randall Wood wrote:
Have you tried using revision -1 (negative 1) for your private ports? On 9 Oct 2006, at 23:23, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
Would people mind defaulting the revision to 1?
I don't know how this would be rolled out. It would cause a massive upgrade.
Regards, Blair
--Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Kevin Van Vechten wrote:
Revisions should be a monotonically increasing serial number (think SVN revisions) indicating the revision of the Portfile.
The purpose of the revision is to provide a unique primary key for every portfile: {name, version, revision}.
- Kevin
Right. And it would be good to have a space for development versions. With RPMs, the default revision people use is 1, so if I want to roll some beta RPMs out to people, I commonly use 0.01, 0.02, etc. It gives me a lot of space to get issues fixed, and then when I'm happy with it, I bump the revision to 1. Regards, Blair
I'm saying revisions should be interpreted as they are in Subversion -- monotonically increasing serial numbers. You can't agree with me _and_ want to "leave space for development". Trying to arbitrarily pick revision numbers, encode special significance into them, and avoid collisions with other developers is fraught with peril. Revision numbers indicate that something about the Portfile has changed aside from the name and version. The decision as to what's development or what's stable needs to be made out of band with respect to revision numbers. Again, using Subversion as an analogy, that's what tags/branches are for. - Kevin On Oct 10, 2006, at 12:54 PM, Blair Zajac wrote:
Kevin Van Vechten wrote:
Revisions should be a monotonically increasing serial number (think SVN revisions) indicating the revision of the Portfile. The purpose of the revision is to provide a unique primary key for every portfile: {name, version, revision}. - Kevin
Right. And it would be good to have a space for development versions. With RPMs, the default revision people use is 1, so if I want to roll some beta RPMs out to people, I commonly use 0.01, 0.02, etc. It gives me a lot of space to get issues fixed, and then when I'm happy with it, I bump the revision to 1.
Regards, Blair
On Oct 9, 2006, at 8:23 PM, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
Well, to keep revisions sacrosanct , which kvv argues for and I agree with, another option might be to use small negative epoch values. I believe epoch defaults to zero. So if you used a small negative epoch for your internal development, and removed epoch on release, I believe you'd have a solution to your problem. Assuming that all the epoch comparisons work correctly for negative numbers, which they probably do. You'd need to do some testing to figure verify this. The nice thing, of course, is that maps well to the intended use of epoch: version numbering in entirely different spaces. James
This would enable me to have a local port, say subversion 1.4.1-0, and then when the real subversion 1.4.1-1 comes out, I'll get an out of date warning.
Also, is the revision an integer, a floating point value, or does it compare values like the version number, it 0.10 is greater than 0.9?
Would people mind defaulting the revision to 1?
I don't know how this would be rolled out. It would cause a massive upgrade.
Regards, Blair
-- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
I don't see the need to have revision numbers be integers. And I'm not suggesting that non-integer revision numbers be committed into svn. I do think that only released, integer revisions should be committed. And using branches for maintaining individual Ports will be a pain, although you could switch those specific directories to a branch. But even then, that won't work for people who don't have commit rights to our Subversion repository, since they won't be able to commit a development version on a branch. So having non-integer revision numbers seems to be the easiest way. Regards, Blair Kevin Van Vechten wrote:
I'm saying revisions should be interpreted as they are in Subversion -- monotonically increasing serial numbers. You can't agree with me _and_ want to "leave space for development". Trying to arbitrarily pick revision numbers, encode special significance into them, and avoid collisions with other developers is fraught with peril. Revision numbers indicate that something about the Portfile has changed aside from the name and version. The decision as to what's development or what's stable needs to be made out of band with respect to revision numbers. Again, using Subversion as an analogy, that's what tags/branches are for.
- Kevin
On Oct 10, 2006, at 12:54 PM, Blair Zajac wrote:
Kevin Van Vechten wrote:
Revisions should be a monotonically increasing serial number (think SVN revisions) indicating the revision of the Portfile. The purpose of the revision is to provide a unique primary key for every portfile: {name, version, revision}. - Kevin
Right. And it would be good to have a space for development versions. With RPMs, the default revision people use is 1, so if I want to roll some beta RPMs out to people, I commonly use 0.01, 0.02, etc. It gives me a lot of space to get issues fixed, and then when I'm happy with it, I bump the revision to 1.
Regards, Blair
James Berry wrote:
On Oct 9, 2006, at 8:23 PM, Blair Zajac wrote:
When I'm developing a new port or want to override the default port in MacPort's svn with a local port of a newer upstream release, it would be nice to have a range of revision numbers that is smaller than any revision number from MacPort's svn repository.
Well, to keep revisions sacrosanct , which kvv argues for and I agree with, another option might be to use small negative epoch values.
I think committed revision numbers should be integers, but start at 1.
I believe epoch defaults to zero. So if you used a small negative epoch for your internal development, and removed epoch on release, I believe you'd have a solution to your problem. Assuming that all the epoch comparisons work correctly for negative numbers, which they probably do. You'd need to do some testing to figure verify this.
The nice thing, of course, is that maps well to the intended use of epoch: version numbering in entirely different spaces.
I haven't tried epochs, but will (epoch=1, name=subversion, version=1.4.1, revision=21872) be greater than (epoch=0, name=subversion, version=1.4.0, revision=0)? Here 21872 is the HEAD revision for Subversion's repository. Does epoch trump version and revision numbers. I wasn't clear concerning how I manage local ports and how I would like them to work. 1) I set up my own Port repository and enable it in /opt/local/etc/ports/sources.conf. 2) I develop an updated Portfile for my local Port repository. I use epoch=-1 or revision=0.01 or some technique. 3) I submit the patch into Trac. 4) When the Port owner commits the patch, my version is automatically outdated and I update to the official version. Currently, I have no way of maintain my own port that will be outdated by an official Portfile, because the default revision is 0. Regards, Blair
On Oct 10, 2006, at 2:04 PM, Blair Zajac wrote:
I haven't tried epochs, but will (epoch=1, name=subversion, version=1.4.1, revision=21872) be greater than (epoch=0, name=subversion, version=1.4.0, revision=0)? Here 21872 is the HEAD revision for Subversion's repository. Does epoch trump version and revision numbers.
Yes, epoch is the most significant thing. It will win over version and revision. epoch defaults to 0 if it's not present, which is why I suggested that you might want to use a negative epoch for your internal use. James.
Epochs are intended to be rarely used, only when the upstream version is inherently 'broken'. Normally some magic version comparison is done that "does the right thing" and determines that 1.4.1 > 1.4.0. However, sometimes this isn't possible, take for example foo-1.4.0, foo-20061010, foo-1.4.1 (released in that order). The normal version comparison won't work, so the epoch provides a workaround by being more significant than the version. In order to make this example collate properly, you'd want to have: { name = foo, epoch = 0, version = 1.4.0, revision = 0 } { name = foo, epoch = 1, version = 20061010, revision = 0 } { name = foo, epoch = 2, version = 1.4.1, revision = 0 } It seems to me that separating the development ports from the official ports is best achieved by manipulating the port sources, not by overloading or redefining the meaning of epochs and revisions. - Kevin On Oct 10, 2006, at 2:49 PM, James Berry wrote:
On Oct 10, 2006, at 2:04 PM, Blair Zajac wrote:
I haven't tried epochs, but will (epoch=1, name=subversion, version=1.4.1, revision=21872) be greater than (epoch=0, name=subversion, version=1.4.0, revision=0)? Here 21872 is the HEAD revision for Subversion's repository. Does epoch trump version and revision numbers.
Yes, epoch is the most significant thing. It will win over version and revision.
epoch defaults to 0 if it's not present, which is why I suggested that you might want to use a negative epoch for your internal use.
James.
participants (5)
-
Blair Zajac
-
James Berry
-
Kevin Van Vechten
-
Michel Salim
-
Randall Wood