Perhaps I should be more specific and clarify my thinging. I see a label
as an immutable property attached to a directory in a specific revision.
That is, the label has a location both in the directory tree and the
revision history that is fixed. One easy eay to do this is with
properties, of course.
Now, as with properties, I can create a label with the same TEXT (name)
as an existing label as long as it exists at a new (dir,rev) location in
the repo. This means I can (a) assign the same label to different
directories and (b) re-assign the same name to a later revision, even in
the same directory.
So what are the semantics of such a model? It means that when I want to
perform an operation on a repo, I specify an URL and a label (presumably
as an argument to the --revision switch). SVN should then search
*backwards* in time looking in the directory specified by the URL for a
label match. When it finds a match, that specifies the revision number
for the command. The URL@REV syntax could also be used to specify a
starting point for the search, so that it is possible to find older
revisions when a label name is re-used.
Pros:
-- Pretty each to implement, although performance may be an issue unless
labels are indexed.
-- Each project/directory has its own label namespace, so no collisions.
-- Labels can be assigned at multiple levels: one set at a project
level, another at a product level etc etc as desired
-- Does not impose any pre-existing ideas about structure of repo (like
current svn philosophy)
-- Labels can be reused over time, making fixing mistakes easy
-- Label changes are transacted and versioned just like other SVN data
-- Avoids many manual searches through logs and cut/paste operations to
get rev numbers
Cons:
-- Someone has to implement this and debug it (I'm strapped for time
right now)
-- Possibly too easy to screw-up by re-using a prior label on a newer
revision, which could cause havoc (fix is to not allow w/o special switch)
-- May be slow doing search for label
--Tim
David Weintraub wrote:
>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
>
>
>
Received on Fri May 13 22:31:43 2005