On Mon, Jul 16, 2012 at 3:33 PM, C. Michael Pilato <cmpil...@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
