Re: Is label support in future release?

I don't see how they increase working copies. If the repository is

projectX/
  trunk/
  branches/
    b1/
    b2/
  tags/
    t1/
    t2/

And the project contains say 20,000 files and 2,000 folders you don't
checkout /projectX and get 100,000 files and 10,008 folders. Instead
you checkout /projectX/trunk and get 20,000 files and 2,001 folders.

You only get more files/folders in your working copy if you have
multiple working copies. Of course this is a completely separate
issue from the extra files associated with pristine copies.

... Hypothetical location where I'm keeping my working copies
> cd /work

...Checking out the trunk to a default working copy.
> svn co svn://server/repos/projectX/trunk default

...Entering the working copy and switching it to a different branch.
> cd /work/default
> svn switch svn://server/repos/projectX/branches/b1

...Where is my working copy right now?...
> cd /work/default
> svn info

Hopefully that's all right... I'm still rather green.

Surely creating the tags and branches are immediately commitable and
so are repository commands rather than working copies in most
situations.

--
Talden
On 15/11/06, Joseph Mocker <mock+svn@fakebelieve.org> 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".
>
> 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