On 2001-08-01 21:55:52 Ben Collins-Sussman wrote:
><peter.westlake@arm.com> writes:
>
>> 1. Name of the root directory
[explanation deleted - thanks]
>If I were to leave off the '-d' argument to checkout:
>
> $ svn checkout http://foo.com/svn/repo/trunk/paint
>
> paint/Makefile
> paint/canvas.c
> ...
Hmm... so what rune would get you
trunk/paint/Makefile
trunk/paint/canvas.c
...
?
>> 3. Where are clones created?
...
>Look at the very last section of the "Future" chapter in the design
>doc. The issue of how to present clones to the user is tricky; we've
>been putting it off for a year, and it's the Big Issue we need to
>tackle when we move from Milestone 3 to Alpha. Very soon!
>
>One proposal on the table is to "encourage" administrators to use a
>policy of laying out the repository like this:
>
> /trunks/proj1
> /proj2
> /branches/proj1
> /proj2
> /tags/proj1
> /proj2
>
>Or possibly, they could have a structure like this:
>
> /proj1/trunk/
> branches/
> tags/
> /proj2/trunk/
> branches/
> tags/
>
>It might be a Good Thing to encourage such policies. Otherwise,
>you'll have to pray that users are *really good* about choosing
>descriptive names for directories that are 'clones' and meant to
>behave as branches or tags. The weight of interpreting a directory as
>a "tag" or "branch" rests on the users' shoulders, because there ain't
>no such things from the filesystem's point of view. :-)
>
>Just food for thought.
I think the best approach might be to put all this food for thought
into a cookbook. The examples you've given are pretty clear, and
illustrate the point that there is more than one way to organise
branches and tags, Being able to put the branch point anywhere in
the path is very powerful, and it would be a shame to restrict it.
Education is the key, and as you've shown, it can be done effectively.
The crucial feature of a branch that distinguishes it from a mere
copy is the *relatedness* of the copy to its original. It is that
notion of a shared history that makes it possible to do concurrent
development and merges, and it is also useful for recording the
reasons for changes. If you explain this, and emphasize that the
cloning process makes the ideas of "copy" and "relatedness" explicit,
and give examples of the nice things you can do with it, I think the
cloning way of doing things would be accepted very quickly. Examples
of how to translate from the old way of doing things would help too.
If you decide to take this approach, I'll volunteer to help write it.
....hmm. We don't just need *examples* of how to translate a CVS
branch into SVN; the cvs2svn tool needs to be able to *do* it!
That implies choosing an organisation like those you show, and
using it to represent the branches. A choice of styles could be
offered, perhaps. How are the cvs2svn people approaching this?
Peter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:34 2006