On Fri, 2011-10-07 at 11:29 +0100, Julian Foad wrote:
> 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,
> > [...]
> >
> > 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'
Yes, this could be useful, and is the kind of policy configuration I'm
talking about here:
<http://wiki.apache.org/subversion/BranchingMergingTerminology>.
> > 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?
Splitting it wouldn't work for me, because the branch marker information
has no purpose and no defined requirements without the mergeinfo user
interface work; the existence and meaning of the info goes hand-in-hand
with developing some ways in which that info can be used.
When we come to integrate some of this work to trunk, by then the
specification of the branching info will have been worked out, and so
then it may be best to create a feature branch specifically for adding
that (without the mergeinfo changes) if it is complex enough to be
worthwhile doing so.
> > > +/* 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"?
That's not a very good term, and I started by calling it a "branch-root
marker", because it does indeed mark a branch root, but I wanted a name
that says the value of this property is the name of the "code base" or
"project tree" that has been branched, rather than the name of the
branch. I'm open to better ideas.
[...]
> > Or are you suggesting Subversion should have a "project" concept?
> > If so, what is your definition of this term?
It's the "code base" or "tree of files" that gets branched. I expect
(but am not yet certain) that if we introduce "branch" as a concept then
we will need a name for the generic "thing" that is being branched,
otherwise we will never be able to talk clearly about branching.
"Tree" (as in a tree of files) is one possible suggestion, but a rather
poor choice because the "branches" are not branches in that tree but are
rather branches *of* that tree in (conceptually) another dimension.
If I were to drop the idea of identifying the "project" and just have a
property "svn:is-branch-root" with value "*" meaning "yes", then the
need to find a term for the "thing that is branched" would be postponed
for a short time more.
- Julian
Received on 2011-10-07 12:59:46 CEST