Julian Fitzell <julian@beta4.com> wrote:
> I'll let someone else handle the technical reasons but I'll throw in
> that I actually find one revision number simpler.
>
> In CVS, I keep having to add bugnotes that say:
>
> " Fixed in CVS foo.c:1.45, bar.c:1.234, baz/other.c:1.5 "
>
> etc... which sucks. With one revision number log messages you can
> atomically refer to one set of changes with one number. Also one commit
> has one log message, which makes sense. This way you can always undo
> all the changes associated with one commit - you don't have to look at
> log messages to tie together changes to various directories, get all the
> version numbers and apply the updates manually. And you don't have to
> look up the date either.
Moreover you can refer to the source tree 'at revision #NNNN', which I find
quite convenient for checkouts and tarball snapshots.
> I do have a mild concern that it will get unwieldy after 5 or 10 years
> when your revision numbers are huge but the r32xx numbers from
> Subversion don't bother me at all so I have no real evidence to suggest
> it will get worse. The other thing is just to make sure each project
> has it's own repository so the numbers don't get any bigger than necessary.
Perforce uses a similar incremented global revision number.
Perl 5 uses Perforce as its main source repository since 1997, and has reached
change #17914 -- including all changes in maintenance and architecture-specific
branches. Those numbers don't confuse people, and it's very useful to know,
for example, that change #NNNN introduced some bug, or that change #MMMM
corrected some other bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 12:23:14 2002