I'm with Felix on this one: there really is no reason to checkout the
entire repository.
I think you are really going down a path that ultimately leads not to
labels, but to something more like a "named view", that provides a
shorthand way of someone getting the "right" part of a large repo
without needing to be familiar with all the mechanics of tags/
branches etc.
--Tim
On Nov 24, 2006, at 8:34 AM, Chris Lambrou wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 24 22:47:04 2006