Re: I, too, miss tags.

On Monday 27 February 2006 23:42, Rob van Oostrum wrote:

> > On Monday 27 February 2006 18:59, Rob van Oostrum wrote:
> > > Imagine a repository holding a single product like so:
> > >
> > > / -> r300 = SOME_TAG
> > >         /trunk -> r400 = VERSION_2_1
> > >         /branches
> > >                 /project1 -> r100 = VERSION_1_0
> > >                 /project2
> > >                 /project3 -> r200 = VERSION_2_0
> > >
> > > My point was, unless you know exactly where to start looking, how would
> > > you find VERSION_1_0 without starting at / and traverse down the tree?
> >
> > The same way how you find it it the current tags/ dir.
> >
> > More specifically, I would go to the project1/ dir (since I suppose you
> > are

> Trunk and Project1-3 in my example above represent 4 development streams of
> the same product/application/codebase. The tags represent 3 different
> releases of the application.

So now what? In your example, you are labeling trunk, project1 and project3
with independent sets of labels. Fine. What is a problem about it? You will
agree that it makes prefect sense to have trunk-2.1, project1-1.0 and
project3-2.0 released simultaneously?

I hope also that you understand that "r100 = VERSION_1_0" is not a single
label attached to a branch, bu a list of labels. Thus, more complete example
would be:

/ -> r300 = SOME_TAG
         /trunk -> r400 = VERSION_2_1
                         r500 = VERSION_2_5
         /branches
                 /project1 -> svn:labels :
                                      r100 = VERSION_1_0
                                      r178 = VERSION_1_1
                                      r450 = VERSION_2.0
                 /project2
                 /project3 -> r200 = VERSION_2_0
                                      r250 = VERSION_2_1

And so on.

> So not knowing specifically where to look, you'd have to start traversing
> from the root down unless your script is aware of the meaning of the
> repository layout and already knows it only needs to query direct
> subdirectories of /branches, as well as /trunk .

You find lists of labels exactely in the same way how you find tags/ subdir.
Imagine in you above example:

/ -> r300 = SOME_TAG
         /trunk
         /branches
                 /project1
                 /project2
                 /project3
/tags
        /VERSION_2_1

What version does tags/VERSION_2_1 correspond to?

You need some extra agreement to find where tag-branches of trunk live, and
where tags of project1 live, and which is which.

With labels, were is less confusion since a label list attached to project1
clearly indicates versions of project1, as David suggested.

> Once it does find a tag, where does the checkout begin from?

From wherever a user wants to. A tag would correspond 1:1 to a revision
number, just be a more convenient menomic for it. You can chek r100 of trunk,
of project1, or of the whole repo. You can likewise check out VERSION_1_0 of
the project1 (and this would be a default), bu you can also co a trunk at
(project1) VERSION_1_0. Why not?

> Do you find the location of the tag
> first, and then run the checkout command separately passing the retrieved
> URL & tag/revision?

I would pass a revision number derived from a label, and check out whatever
URL working copy is bound to. By default, a label would be taken from the
list in the root of the current WC -- this makes most sence, and is fastest.

-- 
Dr. Saulius Gražulis
Institute of Biotechnology
Graiciuno 8
LT-02241 Vilnius
Lietuva (Lithuania)
fax:          (+370-5)-2602116
tel.: office: (+370-5)-2602556
      mobile: (+370-684)-49802, (+370-614)-36366
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org