On 5/12/05, Tim Hill <tim@realmsys.com> wrote:
> I, for one, have never seen a label as anything more than a symbolic
> name for a revision that *cannot* be changed -- it's set at commit time
> (e.g. as a --label flag on svn commit) and that's the end of it, apart
> from the ability to use the label again in "--revision" switches.
In theory, a label should never change. In practice, they get changed.
Many times, I've done a build, completed the build, and then have a
developer announce they forgot to include a small change in a file.
The choice is either going through a whole new release and label
process and thus generating another label, or modifying the label to
include this one change.
Even with a "zero time" labeling scheme, it is sometimes easier to fix
a label than to go though another release process and produce a new
label.
I also disagree that a label should simply be an alias to a revision
number. Imagine a repository in this setup:
/proj1
/tags
/branches
/trunk
/proj2
/tags
/branches
/trunk
I am doing a release for project 1 and calling it VERSION_1.0. If a
label was simply an alias to a revision number, I am applying this
label not just to project 1, but to project 2. I am also applying this
label to the tags and branches directories too.
Yes, I could have naming conventions to help me understand which
project or branch a label really belongs to, and which ones it
doesn't, but I'm again having to rely upon convention to help
implement my labeling scheme.
I also see problems with implementing a label via property. Where
would this "property" be placed? On the version of each file that is
in that label? Imagine how long it would take to label 10,000 files.
Imagine having to write the code that not only finds the files to
label, but verifies that each one got labeled. We had to do that in
ClearCase and RCS, and I'd rather be forcibly made to watch Ishtar.
Maybe the property would only be applied to the revision of the
archive's root or to the revision of the root of the tree you want to
label. The first would pretty much limit the usefulness of labels as
making a label a mere alias to a revision. The second would take a lot
of processing power to search, find, and calculate a revision of a
particular file.
And, no matter how you decide to implement it, you'd have to have a
mechanism to prevent it from being moved by everyone. You could use
hooks, but then labels would not be the "first-class" objects that
people are requesting.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri May 13 17:52:10 2005