> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: dinsdag 17 juli 2012 02:58
> To: C. Michael Pilato
> Cc: Bert Huijben; dev_at_subversion.apache.org
> Subject: Re: RFC: Standardizing a 'svn:branch' (boolean) property
>
> 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
As a branch-root is per definition an ancestor of a node, you can't use it
for anything that you can't already handle using the current relative
externals. (It might take some UI work to make it as user friendly, but
nothing new there).
Viewspecs are a nice topic, but not something that we can solve by a simple
thing like defining a property:)
When the inherited properties branch is merged to trunk we probably want to
define a few more common properties to start using the new feature in svn.
(Original use cases for that were things like extending svn:ignore)
>
> 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 :-).
Currently our authz just looks at paths as strings, not at the content of a
repository.
I like the idea though.
(My guess would be that Enversion can handle these cases much easier)
>
> 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.
When you merge, you always merge to HEAD. And we can always change HEAD.
But I see the point that it wouldn't be nice that we would have to change
old tags.
But then, using mutable revision properties for things that you want cached
on the client side for UI-optimization... I don't think that is going to
work.
I don't see a use case yet where we would like to scan history to find old
branch-roots.
Once we know that we want to merge an old/specific url at a specific
revision, we are no longer interested in what is or isn't a branch root.
> - 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?
That leaves the problem: how do we get the property on existing
repositories.
svn copy --branch would allow performing some best practice checks, adding
the property as necessary (and maybe suppressing the automatic subdirectory
creation mentioned by Philip on irc).
I don't think we can just make 'svn copy' fail on common client-side
scenarios, just because we invented a svn:branch-root in 1.8.
svn copy --branch (or svn branch) can have any behavior we want.
Bert
Received on 2012-07-17 17:57:16 CEST