Tim Hill wrote:
> 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.
Hm :-) Good idea.
> 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
Very good :-) I'd be happy if this gives me:
"svn co -r`svn revpropfind --firstonly eq svn:label Build_123 $URL` $URL"
and perhaps also:
"svn co -r`svn revpropfind --laststonly eq svn:label Build_123 $URL` $URL"
mentioned by Daniel Patterson, (although this is still quite lengthy to
type.)
Although I would be completely satisfied with a WORM-kind label /
"mnemonic name for a revision". Please see below.
> David Weintraub wrote:
>
>>On 5/12/05, Tim Hill <tim@realmsys.com> <mailto: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.
You mean, VERSION_1.0 *should be moved* to a bugfixed revision.
I see, but...
>>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.
... when this happens, I'd rather vote to name the bugfixed revision as
VERSION_1.0-bugfix_0001. If you just move the label, you might forget
that one of your customers received the version with the bug.
(This example strengthens my opinion that this kind of labels should
never be changed.)
If you want to fix a name to a certain state of a project (*not* a
certain state of the repository), you might be better off with a tag.
>>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.
Since subversion creates a new version number for the whole repository,
even if the correction is nothing but a change of one byte inside a
comment, I would rather vote for creating a new label ;-) At least,
such a labeling scheme would be exactly what I want, although I admit
that it's less convenient than changeable labels.
>>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.
Exactly - that's what I think it should do: label/give-a-name-to one
revision number of the repository, especially *including* tags and
branches. Because that's what I want to know: "What was the whole thing
like at 'VERSION_1.0'?" If the branches were left out, I could not check
out the branches as they were at VERSION_1.0, same goes for the tags. Of
course, if there are several projects within one repository (why would
you want to do that? Most likely because they share some code, isn't it?),
then either the VERSION_1.0 should deliberately refer to all projects,
or you should use a label like VERSION_1.0_PR2 or such - it would still
apply to the whole repository, but one who is looking for PR1-revevant
stuff can ignore it.
What you think of is not a "mnemonic name for a revision". It is
something that has a functionality somewhere between tags and mnemonic
names for revision. As far as I understand.
>>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.
But that would be *your* convention, I mean, it would only be needed to
help you remember it. So you can put there anything you want. The text
would be irrelevant for the tools that can access a repository-revnum
via label.
>>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.
Let it be a "property" of the revision number ^__^ that would be fast!
>>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.
Here you assume that labels are implemented to be changeable. But if
you just go with Tim Hill's suggestion and labels are immutable,
one-time settings, you don't have that problem. Then it should be
easy for subversion to enforce that any label is unique.
>>--
>>David Weintraub
>>qazwart@gmail.com <mailto:qazwart@gmail.com>
Have fun
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 14 19:01:25 2005