Re: Simple Label=RevisionID Discussion

On Wed, Nov 22, 2006 at 09:49:01AM +0100, Robert Graf-Waczenski wrote:
> > 2. How many labels can be attached to a revision? One? Any number?
>
> Only one. (Remember, we're talking *poor* man's labels here...)

So adding a new label to the rev destroys the old label? I think this
is wrong. Any given revision should be able to have the same label.
Especially with mutable labels you may need to double label a revision
with a permanent label (say PRODUCTION_2006_11_22) and a floating
lable (CURRENT_PRODUCTION).
 
> > 3. When are labels attached? Using a discrete comment? Using a new
> > commit-time switch (which would need to include other "commit" type
> > commands like copy/import)?
>
> I'm not sure what you mean here. The label should be attachable any
> time to any revision that exists in the repo.

Then this argues for non-revisioned properties in which case multiple
labels may be even more important.

> > 5. If rev N has label X can ren M have the same label? How should the
> > tools behave in such a case when choosing a rev# based on label?
>
> That's something i actually overlooked. You are right, label texts must
> be unique, i.e. if rev N has label X, then rev M can not have the
> same label.

Initially yes there should be only one copy of a unique
label (as in CVS for example) on a file.

However we do have peg revisions in SVN so it is possible to start in
the middle of the revision tree and search backwards from that point
for the label.

E.G. on file http://.../foo.c

  label revision
               8
  PRODUCTION 10
  PRODUCTION 12
  PRODUCTION 15

If I co/update

  -r PRODUCTION http://.../foo.c

I get version 15. If I use:

  -r PRODUCTION http://.../foo.c@14

I get revision 12

and

  -r PRODUCTION http://.../foo.c@11

gets rev 10

  -r PRODUCTION http://.../foo.c@9

gets nothing since there was no production tag prior to that point.

This provides a way to get at prior PRODUCTION tags and reconstruct
them.
 
> Moreover, i also overlooked the following, which does not directly
> apply to the PML label feature but rather to the way that for example
> the svn toolchain gives access to the label information:
>
> Say for example that file F1 has been changed at revs 7 and 15 and
> that HEAD currently is 18. Now i attach the PML "Rel 1.0" to rev 10
> and the PML "Rel 1.1" to rev 18. Now i want to see that F1 has seen
> changes at revs 7 and 15 (which is already supported via "svn log")
> and that there were labelled revisions *between* 7 and 15 and *after*
> 15. By piecing this information together, i know that the F1 change
> at rev 7 was released with release 1.0 of my product and that the
> F1 change at rev 15 has been released with 1.1, so if the F1 change
> at rev 15 introduced a bug, then i know that release 1.0 doesn't have
> the bug yet, which is what i'm aiming at.
>
> I'm thinking of a new subcommand (called for example "svn labels")
> which would quickly list all labels that have been set on the repo
> globally.

Or maybe just a flag to svn info?

-- 
				-- rouilj
John Rouillard
System Administrator
Renesys Corporation
603-643-9300 x 111
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org