[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of the 'showing-merge-info' branch

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 28 Oct 2011 09:38:57 +0200

On Fri, Oct 28, 2011 at 1:33 AM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> Johan Corveleyn wrote on Thu, Oct 27, 2011 at 22:24:19 +0200:
>> On Thu, Oct 27, 2011 at 3:57 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> > On Thu, Oct 27, 2011 at 8:11 AM, Julian Foad <julian.foad_at_wandisco.com>
>> [...]
>> >>
>> >> [[[
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches/1.6.x
>> >> Branch marker: 'subversion-source-tree' (found on both source and target)
>> >> [...]
>> >>
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/branches
>> >> svn: E195016: Source branch marker is 'subversion-source-tree' but
>> >> target has no branch marker
>> >>
>> >> $ svn mergeinfo ^/subversion/trunk ^/subversion/trunk
>> >> svn: E195016: Source and target are the same branch
>> >> ]]]
>> >>
>> >> This looks for a branch root marker property on the specified
>> >> directory. The property name would be 'svn:branch-root' and the value
>> >> would be a string that (more or less uniquely) identifies the
>> >> 'project' (for want of a better word) of which this is a branch.
>> >> Currently, just for testing, the property it looks for is the first
>> >> ten characters of 'svn:ignore', which tends to work moderately well
>> >> for ad-hoc testing against our own source tree because it exists and
>> >> starts with 'ChangeLog*' in the root of every branch and (I guess)
>> >> nowhere else.
>> >
>> >
>> > This feature concerns me the most.  I assume we are not proposing to add
>> > this marker just for this one subcommand?  I would like to see the big
>> > picture of what we would do this marker so we can discuss its format and its
>> > ramifications.
>> I agree with this. A branch-roots feature can be very useful in a lot
>> of contexts, and I'd like it to be carefully designed to address some
>> shortcomings in branching/merging (and potentially tagging as well).
>> For instance, it'd be nice if you could refer to the "current branch
>> root" at the command line, or in externals definitions (externals
>> relative to the branch root), or even in viewspec files
>> (svn-viewspec.py). Or if you could say:
>>     svn merge --reintegrate branch:showing-merge-info
>> which would look for the branch-root called 'showing-merge-info', part
>> of the same 'branch-marker-space'. Or something like that (just
>> throwing ideas in the air).
>> Or:
>>     svn diff tag:MyApp:rel-1.0 tag:MyApp:rel-1.1
>> (where 'MyApp' is the 'branch-marker', and rel-* are the tags in that
>> 'namespace').
> Quick observation: you're asking the question "Where does the branch
> named %s live" (and I consider tags a special case of branches for the
> purposes of avoiding having to invent terminology at 2am), Julian is
> asking the question "What branch is URL %s member of?".  These two
> questions don't seem directly related, my first hunch was that they're
> quite opposite.

Hm, indeed it's not the same question.Except if you structure your
branches in such a way that it is (which is the case in our
environment): all branches of branch-marker "MyApp" are put in
^/branches/MyApp (same for tags). So we effectively use the branches'
parent dir as the "branch-marker" ... or something like that :-).

Maybe "branch-context" is a better name than "branch-marker"?

Thinking further about it, I think it makes some sense to establish a
link between the branch-context, and the place where the branches
live. For one thing, it helps to make sure that there are no name
collisions between branches within the same branch-context. And people
using SVN are quite used to the fact that branches/tags are part of
the directory structure.

OTOH, maybe people want to get rid of the fact that branches/tags are
related to directories in the repository, and may want to ignore that
a branch is located at a particular path. And if you move
branches/tags around, you may want the branch-context to stay the same
... I really don't know, I haven't thought too deeply about this.

> ---
> Independently: can branches be nested?  Say, can we have
>   /subversion/trunk/tools/calc/trunk
> which gets carried along to
>   /subversion/branches/1.7.x/tools/calc/trunk
> and then branches
>  /subversion/trunk/tools/calc/branches/my-calc-branch
> and then someone backports that to the 1.7.x branch of calc
>  /subversion/branches/1.7.x/tools/calc/branches/my-calc-branch
> and then someone asks what branch is that last thing a part of...

Yikes, that would be very confusing. I'd say (from an enterprise /
user standpoint): don't do that. If possible, this should be
disallowed, maybe blocked by one of those branch/merge-policy things
that were mentioned elsethread...

Received on 2011-10-28 09:39:49 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.