Julian Fitzell <julian@beta4.com> writes:
> 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.
Yes, a single number is definitely more convenient than a list of
numbers. Each revision is just a name for some changeset, some
particular commit. From a CVS point-of-view, it's as if the system
automatically created a tree-wide tag everytime somebody made a
commit.
From the technical side, this design makes it easy to remove or
examine a commit as a single entity. It's also the reason that we can
create branches and tags in constant time, whereas in CVS it's an O(N)
operation. Checking out branches and tags is much faster as well.
Our "series of trees" is also our mechanism by which we version tree
structures, i.e. additions, deletions, renames.
The important thing to remember is that the revision numbers don't
necessarily mean very much. We could have given them names like
"a8eff381c", or any old set of orderable strings. But instead, we
decided to expose this metadata to users as integers, because it turns
out to be very handy. Remember that they have nothing to do with your
actual software release numbers, no matter how large they get.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 24 17:05:13 2002