On Mon, Jul 16, 2012 at 3:33 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 07/16/2012 08:11 AM, Bert Huijben wrote:
>> On the Berlin hackathon the suggestion was raised that it might help that we
>> standardize a new 'svn:branch' property to give tooling a hint on what
>> directories are branches and which aren't. To make sure we don't forget
>> about this idea I just drop this on the list with the information I have. I
>> hope others can extend this proposal with their own ideas.
>
> This is not the first time this topic has come up:
>
> http://svn.haxx.se/dev/archive-2009-09/0156.shtml
> http://svn.haxx.se/users/archive-2009-09/0292.shtml
> http://svn.haxx.se/users/archive-2009-02/0729.shtml
It also came up in some more recent discussion started by Julian:
http://svn.haxx.se/dev/archive-2011-10/0406.shtml
(there was some talk in there of a 'project' or 'branching-space'
concept, to keep related branches/tags together (and maybe also to
create a namespace for them), but that might go a bit too far for now
... and lots of other complexities are lurking behind those concepts).
>> As we couldn't think of a usage of the content I would suggest that we just
>> always set the property to '*', just like how we handle svn:executable,
>> svn:needs-lock, etc. This would also make sure that merges of this property
>> won't need special handling.
>
> +1. Let's get the mechanics for recognizing branch roots in place first.
> We can worry about additional policy matters later when we have a better
> idea what our users might require.
+1 to some support for branch identification. But I'm not sure if such
a simple property will provide that in a good way. OTOH I don't have a
better suggestion now.
First, a couple of use cases I have in mind if branch-roots can be identified:
1) branch-root-relative urls, making possible:
- branch-root-relative externals
- branch-root-relative viewspecs
2) branch-root-relative authz?
- Say "//" is a wildcard for branch-root:
[repos://private-dir] # "/private-dir" in any "branch" of repos
[repos:/tags//dir/public] # "/dir/public" under any "branch" below
"tags" of repos
- Dunno if this is technically implementable for authz. So this may be
a not-so-good use-case :-).
But, with the "marker-property" approach, and following Trent's
explanation of Enversion, I worry about:
- How to retrofit an existing repository with branch-root
identification on historical branches/tags? Enversion's solution of
using revprops seems currently the only way we have to "annotate"
history.
- How to automate the annotation of existing branches?
Both of these concerns are less of a problem for new repositories (if
trunk is marked as branch-root, all new branches/tags created from
there will be branch-roots as well). But then for new repositories
there is another concern:
- How to ensure users won't forget to mark their new trunk(s) as
branch-root(s)? I can perfectly imagine a furious mail to users@
saying: "I'm at r250000 now, and you're telling me that I should have
marked 'trunk' with the svn:branch-root property (or should have
created 'trunk' with 'mkdir --branch') back at r1 to get proper branch
support for features X, Y and Z??? And I can't correct this situation
now (historically complete), without doing a dump/reload causing all
my users to checkout new working copies?"
Finally:
- We wouldn't need "svn copy --branch" would we? Only "svn mkdir
--branch" and regular "svn copy" (which propagates the marker property
anyway)? Right?
--
Johan
Received on 2012-07-17 03:05:07 CEST