Labels [was: RE: Accidental double tag copy]

> -----Original Message-----
> From: David Weintraub [mailto:qazwart_at_gmail.com]

> Basically, a label would simply be an alias to a revision. For
> example:
>
> $ svn mklabel REL-1.0 12345
>
> This would make the label REL-1.0 synonymous with revision
> 12345. This means you could now do things like this:
>
> $ svn diff -rREL-1.0:HEAD
>
> or
>
> $ svn update -rREL-1.0
>
> I know there are some limitations with this:

> * A label would be across an entire repository. If I have
> multiple projects, I can have a separate tag directory for
> each project.
> Creating a label for project "A" would also create a
> meaningless label for project "B".

Why?

A label *could* be mapped to a pinned URL.

If they're implemented as properties, then should they be
versioned or not?

E.g., would you want labels like "experimental", "stable"?

Should they be stored effectively at the repository root,
(where they're easier to find, but where there will be more
"clutter") or with the directory being labelled?

> I know that Subversion works fine without "labels", and you
> can provide shell scripts to emulate this stuff, but it would
> be nice to have something like this built into Subversion.
> And, developers would find Subversion a bit easier to use and
> comprehend.

I think there are already all the tools required to "emulate"
labelling (as David has already noted). SVN has tags, versioned
properties and unversioned properties.

With labels, its certainly nice to have meaningful names, such
as "version 1.0.1", but then that can be captured by the name
of the target of the copy.

----
However, I *do* think that SVN could be vastly improved with
better "support" of tags. Sometimes it would be useful to do an
    svn log
with interleaved tag information: that is, show the history along with
the revisions forming the *sources* of copy commands.
This could perhaps be done by having a (versioned)
    svn:copy-area
property containing a (list of) tag and/or branch areas of interest
associated with a directory
Then a command such as
    svn log --show-copies
could first search up through the tree for an svn:copy-area property,
(probably stopping at the first one found)
perform a log of those areas, noting any copy operations, and display
interleaved log information something like this:
Suppose the "svn:copy-area" for /project/trunk has value
    /project/branches
    /project/tags
then a log "with copies"
    $ svn log --show-copies -r100:200
might result in
 
------------------------------------------------------------------------
  r100 | user | YYYY-MM-DD HH:MM:SS +0000 (Day, DD Mon YYYY) | N lines
  Comment
 
========================================================================
  "v1.0.1"
     A /project/tags/v1.0.1 (from /project/trunk:112)
 
========================================================================
  r125 | user | YYYY-MM-DD HH:MM:SS +0000 (Day, DD Mon YYYY) | N lines
  Comment
 
------------------------------------------------------------------------
  r150 | user | YYYY-MM-DD HH:MM:SS +0000 (Day, DD Mon YYYY) | N lines
  Comment
 
========================================================================
  "feature-x"
     A /project/branches/feature-x (from /project/trunk:170)
 
========================================================================
  r175 | user | YYYY-MM-DD HH:MM:SS +0000 (Day, DD Mon YYYY) | N lines
  Comment
 
------------------------------------------------------------------------
This can of course be scripted, but it would be great to have this sort
of support directly.
I think the sort of syntax David mentioned could also be supported with
an approach similar to this. Other than a new "svn:copy-area" property
I don't think any further "scaffolding" is required. However, providing
the functionality itself is not entirely trivial...
Possibly, it would be better to have the "svn:copy-area" in the
working copy rather than the repository. But this was only intended to
be the beginnings of an idea...
Rob.
_______________________________________________
This email has been scanned for Softel by Star.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org