This might be somewhat off topic, but the problem I see with tags and
branches as they are supported in Subversion is that they lead to such
an exponential growth in working copies such that there is no way one
could checkout an entire project, even moderately sized (2000 files, 100
tags) including trunk, tags & branches without taxing resources in some
way (disk, cpu, developer time)
The downside is that developers need to learn tricks to deal with this.
For example, developers should only checkout the trunk, but that isn't a
one step operation if you want to preserve directory structure of say
project/trunk. First I must "svn checkout -N project", then "cd project;
svn update trunk".
That way when I create a tag, I can just "cd project; mkdir tags; svn
add tags; svn copy trunk tags/tagname". Straight forward, just not a
single operation, and the more operations, the more possibility to
foobar something.
--joe
Talden wrote:
> I don't know that the effort of creating a label would be any less...
> but some common manipulations might be.
>
> 1) moving a label means removing the old and recreating it - no need
> for history since a label is a point in history. Moving a tag is a
> delete and a recopy which does turn up in history.
>
> 2) listing logs between two labels (since they're revision aliases) is
> trivial. Doing the same from tags is non-trivial requiring two logs
> with stop on copy to get the revisions in question.
>
> Perhaps if we were to list all of the expected uses of labels, then
> for each use discuss what the existing facilities provide for in the
> way of solutions. We then need to postulate as to how labels would
> either better facilitate these processes and perhaps what
> functionality labels might give beyond what is practical using
> existing facilities.
>
> I expect such a formal approach will be the only means by which you
> convince existing developers (or draw in new developers) to add this
> feature.
>
> I'll start with the obvious simple case.
>
> 1. Labels provide a contextual and memorable alias for a revision number.
>
> A tag can do this as well. You create the tag and then when you need
> the revision number it refers to you must execute a log 'stop on copy'
> command on the tag URL.
>
> A label on the other-hand is an explicit alias for a revision number
> and could be used directly.
>
> svn label -rN pre_import_checkpoint
> ...
> svn log -rpre_import_checkpoint:HEAD ...
>
> --
> Talden
>
> On 15/11/06, Nikki Locke <info@trumphurst.com> wrote:
>> Phyrefly wrote:
>> > I agree, tags provide all the needed features, but they're far too
>> > complex (and expensive in terms of ease-of-use if nothing else) to be
>> > used as labels. I would like to be able to label my repo at the point
>> > I do a release, but I have no intention of treating it as a branch,
>> > just a convenient way of getting that code back. Currently I'm using
>> > the datestamp on my release log as a means of doing an export of a
>> > particular point in the repo's history.
>>
>> What's the ease-of-use difference between creating a tag, and
>> creating a "label"?
>>
>> What command would you run to create a label?
>> How does that compare with the command you would run to create a tag?
>>
>> --
>> Nikki Locke, Trumphurst Ltd. PC & Unix consultancy & programming
>> http://www.trumphurst.com/
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 14 22:48:29 2006