Jim Blandy wrote:
> Here's a revision of my original suggestion that handles deep branch
> directories nicely. Skip down to 'we will expand arguments'; not much
> above that has changed.
[...]
> # - First, assume that our current working directory is based on the
> # repository path BASE.
> #
> # - Find the lowest parent of BASE that has a property named
> # 'svnp:parallel-root'. (The value of this property must be '.';
> # don't worry about that for now.) This marks the root of a tree
> # which has parallel trees elsewhere. Call this directory PROOT.
> # Since it's a parent of BASE, there's some RELBASE such that
> # PROOT/RELBASE is BASE. PROOT may be BASE itself, in which case
> # RELBASE is '.'.
> #
> # - Find the lowest parent of RELBASE that has a property named
> # 'svnp:parallel:KIND'. Its value should be an absolute repository
> # path; call that KINDROOT.
I believe that should have said, "Find the lowest parent of PROOT that ...".
> # - Replace the '+KIND[/SUBDIR]' argument with the string
> # 'KINDROOT/SUBDIR/RELBASE'. (Use '.' for SUBDIR if it's absent, or
> # just omit that path element altogether.)
> #
> # So, the root of every parallel tree needs to be marked with
> # 'svnp:parallel-root', and at some parent directory common to all
> # your parallel trees you need a bunch of 'svnp:parallel:KIND'
> # properties.
Your plan is looking promising.
The biggest restriction I see is that it only supports one level of branches.
By that I mean that for any given file F, the branches that contain F will all
have been copies of the same (project-root) node N. We, the Subversion
developer community, typically only create branches of a "whole project", but
sometimes a "whole project" is not as identifiable as it sounds. For example,
the documentation team might like to create a branch of just a "doc" sub-tree
for adding mark-up, so:
/trunk/proj1 --> /branches/proj1/release/v1.0.x
/trunk/proj1/blah/doc --> /branches/proj1/doc/add-markup
Though we might recommend against it, it's inevitable that some people will
need, and some will use, multi-level branches such as these. Any new feature
for addressing branches must support these to some reasonable extent because it
is in these more complex projects that people stand to gain most from the feature.
Can you extend your proposal to make these complexities _possible_ without
necessarily being as easy as the basic scenario? Part of this extension would
presumably be something like "If the first properties found when walking up the
tree don't lead to finding a branch of the given name, then walk further up and
try again."
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 13 20:18:09 2005