John, I think you've overlooked some use cases for tags. Here are three
to consider.
Tagging the working copy, e.g., after a successful build, involves
copying a directory in the repository, *and* committing all the working
copy modifications to the copy. In this type of tag, the copy contains
some information found nowhere else in the repository, so it can't be
represented by a URL and revision.
A working copy can contain a mix of different revisions of
subdirectories, e.g., for testing backward compatibility of a component.
Making a tag of such a mixed revision working copy provides a handy way
to save a particular constellation of projects. A mixed revision tag
can't be represented by a single URL and revision.
Moving the contents of a repository, via dump and load, does not
preserve revision numbers. Tags-as-copies are preserved when a
repository's contents are moved. If a tag was only a synonym for a URL
and revision, then they would not be preserved across repository moves.
These three scenarios are all important in our development. I assume
there are other tag use cases.
I'd be surprised if the concept of tagging in Subversion was the best it
could possibly be. As far as I can tell, your proposed replacement for
tags has less functionality than the current solution. Can your idea be
extended to solve at least all of the problems solved by tags-as-copies,
if not solve additional needs?
Cheers,
Stuart
Stuart Celarier | Corillian Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 19 01:52:20 2006