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

Identifying branch roots [was: svn commit: r1179135 - in /subversion/branches/showing-merge-info/...]

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 07 Oct 2011 11:29:29 +0100

Stefan Sperling wrote:
> julianfoad wrote:
> > +/* This property marks a branch root. Branches with the same value of this
> > + * property are mergeable. */
> > +#define SVN_PROP_BRANCHING_ROOT "svn:ignore" /* ### should be "svn:branching-root" */

Hi Stefan. Thanks for picking up on this.

> I think your addition of a 'branch root' property is quite a significant
> step. Is this really necessary in order to improve the output of
> 'svn mergeinfo' or do you have additional steps planned that go beyond
> tuning output?

Both. I think knowing whether the (requested) merge source and target
are branch roots (and indeed branches of the *same* "project" or tree)
is important for improving the output and diagnostics of "svn mergeinfo"
and "svn merge" commands.

It could of course enable other new behaviours relating to branches, and
I don't know what those are yet (apart from trivial UI things like
answering "is this a branch?").

So I'm working on the idea that it would be useful to have branch roots
identifiable by some mechanism, so I'll add "some mechanism" (currently
this property, but I'm totally open to a different mechanism such as
branch points being defined in a config file) and see what useful
behaviours I can come up with.

> There has been some discussion about adding a property for this
> and similar purposes in the past, see
> http://svn.haxx.se/dev/archive-2009-09/0156.shtml
> (there are probably more threads about this topic)

Yes, and it's time to figure out what we can usefully do with such
information and then we'll know exactly what branch configuration
information we need and what's a good way to store it.

I'll reply to the rest in a further email.

- Julian

> One idea I've had in mind which relates to the notion of a branch root
> is to have a property which specifies the merge policy for the branch,
> called 'svn:mergepolicy' (or maybe even use the 'branch root' property
> itself for this purpose). It could use keywords such as "cherry-pick,
> sync, reintegrate" to define the set of allowed types of merges.
>
> Simple sketch:
> - feature-branch (can only receive catch-up merges from its direct parent
> branch (copyfrom-source), or be reintegrated)
> => svn:mergepolicy on branch root: 'sync ^/trunk
> reintegrate ^/trunk'
>
> - release-branch (cannot be reintegrated into its parent)
> => svn:mergepolicy on branch root: 'cherry-pick ^/trunk'
>
>
> I haven't though this through yet.
> I think your approach of "Branches with the same value of this
> property are mergeable" is a design decision which has a similar
> kind of impact on how a branch-root property would be used.
> How do we really want it to be used?
>
> I think this is an exciting feature with lots of potential but
> it has a lot more inherent complexity than improving 'svn mergeinfo'
> output. Could we split improving the output of 'svn mergeinfo' and
> identifying branch roots into two distinct feature branches?
>
> > +/* Set *MARKER to the project-root marker that is common to SOURCE and
> > + * TARGET, or to NULL if neither has such a marker.
>
> Why do you need to introduce a new term "project"?
>
> > + /* Check the source's and target's branch-marker properties. */
> > + SVN_ERR(get_branch_root_marker(&target_marker, target, ctx, pool));
> > + SVN_ERR(get_branch_root_marker(&source_marker, source, ctx, pool));
> > + if (! source_marker && ! target_marker)
> > + {
> > + /* Old-style branches, not marked as such. Marker will be NULL. */
> > + }
> > + else if (! source_marker || ! target_marker)
> > + {
> > + if (source_marker)
> > + return svn_error_createf(SVN_ERR_CLIENT_NOT_READY_TO_MERGE, NULL,
> > + _("Source is marked as a branch of "
> > + "project '%s', but target is not marked"),
>
> Same here. This terminology can confuse users because Subversion
> doesn't have a 'project' concept.
>
> Why don't you just say "marked as a branch of '%s'"?
>
> Or are you suggesting Subversion should have a "project" concept?
> If so, what is your definition of this term?
>
> More instances of this term are below:
>
> > + source_marker);
> > + else
> > + return svn_error_createf(SVN_ERR_CLIENT_NOT_READY_TO_MERGE, NULL,
> > + _("Target is marked as a branch of "
> > + "project '%s', but source is not marked"),
> > + target_marker);
> > + }
> > + else if (strcmp(source_marker, target_marker) != 0)
> > + {
> > + /* ### The '.99' is just for display tidiness when I'm messing about
> > + * with using 'svn:ignore' as the branch marker property. */
> > + return svn_error_createf(SVN_ERR_CLIENT_NOT_READY_TO_MERGE, NULL,
> > + _("error: Source is marked as branch of project '%.99s' "
> > + "but target is marked as branch of project '%.99s'"),
> > + source_marker, target_marker);
> > + }
> > + *marker = source_marker;
> > + return SVN_NO_ERROR;
> > +}
Received on 2011-10-07 12:30:06 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.