Rather than a label being an alias for a specific revision number, I
think a label should encapsulate both a revision number and a URL or WC
path. I think that a label as a simple alias for a revision number
would be of limited use, whereas I think it's much more useful to be
able to label a specific version of a file or folder. For example, in
any Subversion repository that hosts multiple projects, it's useful to
be able to limit the scope of the label to the specific project that the
label relates to. Of course, this also extends to being able to label
specific branches of a project, or indeed to any sub-folder within a
larger whole. Generally, I'd like to be able to label a part of a
project that I'm working on in a way that's completely transparent to
developers working in other areas of the repository.
I can see such labels replacing tags in some respects. For example, in
my development team we create a complete 'testing' build every couple of
weeks (each time some new testable functionality has been completed and
can be released to our testing partners). Each one of these builds gets
tagged, and whilst this copy operation is inexpensive as far as the SVN
repository is concerned, it is painful for clients to perform an update
on the project root folder, as each tag occupies nearly half a gigabyte.
It's a brave developer who chooses to perform a clean checkout of our
repository. I'm considering replacing the tagging operation in favour
of a simple log file that ties together each testing build name and
number to its associated revision number. It would be much more
convenient for us if this information could be recorded as individual
labels of the trunk folder.
I think a new label command could have the following syntax:
svn label [-r] [PATH]
where
-r Optional revision number (defaults to HEAD)
-PATH Optional WC path or URL (defaults to .)
And there'd also need to be a new command (or a modification of an
existing command - svn info perhaps?) to query the labels that exist in
a sub-folder. Additionally, any command that currently accepts both a
revision number and a path would permit these to be combined using a
single label argument.
e.g. svn copy -r 1000 trunk branches/new_branch
could also be achieved using
svn copy -l some_label branches/new_branch
where 'some_label' associates revision 1000 and the 'trunk' folder, so
that in both cases the 'new_branch' branch is created from the 'trunk'
folder at revision 1000. Perhaps this would require labels in a
repository to unique, which I'm not sure is such a good idea.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 24 17:34:49 2006