<peter.westlake@arm.com> writes:
> >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
> ...
$ svn checkout http://foo.com/svn/repo/trunk
...assuming that there are no other siblings of "paint" in trunk.
The simple rules are:
* checkout will fetch the final directory in the URL, and create
that exact directory locally, with the same name.
* if -d is used, the working copy will have an arbitrary name, but
will still contain the contents of the final URL directory.
> 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.
Like I said, we've been planning on replacing branches and tags with
this "clone" model for over a year, and after we hit M3 on August
15th, this is really the last Huge Task we need to do before getting
to Alpha in mid-September. Obviously, the filesystem already supports
cloning. The Huge Task at hand is writing *client-side* support for
clones. It's a big UI problem, and it's also going to be painful to
write support for things like:
* switching your working copy onto a related clone (branch)
* allowing client-side merging of two clones (branches)
We would absolutely love it if you're willing to volunteer to help us
flesh-out use cases and examples! We've been somewhat documenting
client-side behaviors in our doc/user/manual/ directory, but no doubt
that we really need intense documentation for this new way of working.
If you're willing to write documentation, that would be fantastic.
> ....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?
Indeed, the cvs2svn people are (probably) going to choose one of the
two layouts I described in the previous mail. Or maybe the tool will
let you select one of the layouts.
Not like it really matters -- administrators can simply move
subdirectories around however they wish. They can use any
organizational scheme they want after the conversion has taken place.
---------------------------------------------------------------------
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