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
/ -> r300 = SOME_TAG
/trunk -> r400 = VERSION_2_1
r500 = VERSION_2_5
/project1 -> svn:labels :
r100 = VERSION_1_0
r178 = VERSION_1_1
r450 = VERSION_2.0
/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
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
tel.: office: (+370-5)-2602556
mobile: (+370-684)-49802, (+370-614)-36366
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Feb 28 08:29:45 2006