Joseph Mocker wrote:
> 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".
>
Don't preserve directory structure, just checkout trunk to project
eg.
svn co svn+ssh://svn.example.com/var/svn/project/trunk project
cd project
> 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.
>
Only do svn copy on repository url's
eg.
svn copy svn+ssh://svn.example.com/var/svn/project/trunk
svn+ssh://svn.example.com/var/svn/project/tags/test
svn co svn+ssh://svn.example.com/var/svn/project/trunk project
then locally
do
svn switch svn+ssh://svn.example.com/var/svn/project/tags/test
> --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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 14 23:20:57 2006