I woke up today to two messages from Alan, three from Jim, and four from
Marc Sherman on this thread. I can't fault Alan, but Jim and Marc,
please read the whole thread before sending off replies? When dev
threads grow complex like this, we need people to force them into a more
linear structure. Outside readers cannot follow them if the tree
structure grows too complex. Thanks.
On Sun, 2005-11-13 at 10:46 +0200, Alan Barrett wrote:
> > I'd like to hear how other folks feel about this proposal. Is it
> > general enough? Does it restrict people from doing valuable things?
I think it's nice and elegant, insofar as when you create a branch, the
svn:treeroot property comes along for the ride, and does not need to be
modified. My impression of Jim's proposal (which, sadly, I have not
fully wrapped my head around) is that you'd have to do a bunch of
property-fiddling every time you create a new branch.
But I have another proposal which I think has that nice property as
well, and some other advantages.
> It's not as general as Greg's rewrite rules. Two features that rewrite
> rules could offer that are missing from the projectroot+treeroot
> proposal are:
I threw out that as a straw man in
http://svn.haxx.se/dev/archive-2005-05/1367.shtml .
I'm no longer enamored of that proposal, because I think it's too
general, and users would not be able to understand it without a lot of
effort. That's probably also true of Jim's proposal, and to some extent
Marc's. I now believe the client (though not the server) should
understand the concept of trunk, branches, and tags.
Here's the general idea: a directory property svn:ttb contains the FS
paths of the trunk, tags, and branches directories. The value might
look like "/trunk /tags /branches"; perhaps that could even be the
default, although that's a little dangerous. (Quoting issues might push
us in the direction of three separate properties, svn:trunk, svn:tags,
and svn:branches. Whatever.) Obviously, this is a property we'd like
to have apply to subdirectories somehow, as in the other proposals.
I'm not going to address the client syntax for using this information,
though as I've said before, I still like the idea of generalizing -r so
that a revision specifier can change the URL as well as set the revision
number.
>> If you've got your parallel trees scattered around more, it won't
>> work as well, but maybe the answer is "don't do that".
> "Don't do that" is not very nice advice to people trying to migrate
> from CVS to subversion, because they may already have branches that
> don't cover the entire project. However, perhaps some cleverness (and
> more complex configuration capabilities) in cvs2svn would be good
> enough.
I think it's better to get everyone to a place where they can use a
simple, elegant feature than it is to make a feature everyone can use
but no one can understand.
With my svn:ttb proposal, you could create a branch or tag off part of
the tree which applies to part of the tree and set svn:ttb on that
branch to "/trunk/src/sys /kerneltags /kernelbranches", but it would
only work one way. You could go into /kernelbranches/foo and easily
diff against the trunk, but you couldn't go into /trunk/src/sys and
easily diff against a kernel branch. We could extend the property
syntax so that there are multiple places to look for branches off of
different parts of the tree, but then nobody would understand the
feature any more.
Better, I think, to tell people to move the kernel branches
to /branches/foo/src/sys, so that a kernel branch looks like a branch of
the entire tree with most of the tree missing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 13 17:13:29 2005