revision numbers (was: Re: Single repository, multiple projects?)

[Greg Stein <gs...@lyra.org>]

On Sun, Feb 03, 2002 at 10:25:25AM -0800, Sean Russell wrote:
>...
> (superficially) see projects changing when, in fact, they haven't.  The 
> argument for the current way (AFAICS) is that versions in SVN are, unlike 
> CVS, invisible backend mumbo-jumbo that Normal Users shouldn't deal with 
> much, anyway.

Interesting that you mention that. For a little while now, I've actually
said that the revision number *is* somewhat arbitrary. For the most part, we
don't worry or care that it is a monotonically increasing integer. We do
equality comparisons, but that is about it.

And since we only care about equality, that means it "should be" perfectly
possible to replace the numbers with arbitrary strings.

Not sure what benefit that has :-), but certainly an interesting concept.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: revision numbers (was: Re: Single repository, multiple projects?)

[Sean Russell <se...@germane-software.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 03 February 2002 15:22, Greg Stein wrote:
> And since we only care about equality, that means it "should be" perfectly
> possible to replace the numbers with arbitrary strings.
>
> Not sure what benefit that has :-), but certainly an interesting concept.

Well, what do you get from using integers, and why would you bother using 
anything else?

With integers you get ordering, but that's only interesting if you use 
it; I don't know of any SVN commands that do version (should we say 
primary ID?) comparison except, as you say, for equality.  Also, it is easy 
to increment integers and thereby generate unique IDs.

If you don't use integers, but (say) hex, or even the entire alphabet, you 
could still get ordering and easy increments, and you'd reduce the rate of 
increase in the number of digits.

More interesting would be if you could pass SVN the version string you wanted 
it to use for a commit; it would be a sort of even cheaper tag:

   svn ci -v 1.2.6

would use 1.2.6 as the version for that particular commit.  No need to do a 
tag, although you'd still need to do branches the old way.  Or you could use 
date strings, or other tag-like strings ("alpha-3").

This is marginally less useful when you have one ID for the entire database, 
because you'll increase the chances of encountering an ID conflict. On the 
other hand, because SVN commits are atomic, a version conflict wouldn't be a 
dangerous thing.

Yes, Greg, very interesting.

- -- 
 |..  POLITICALLY CORRECT: A phrase used to limit people's freedom of
<|>    thought cf. Moral Majority.
/|\   
/|    
 |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8XehFP0KxygnleI8RAhX6AKCkm89566pl7MXb1jTAM2FBz0LYsgCgywyA
MIpWuAZlC2lfNb4CMwlWJgU=
=nXOf
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org