Re: Merge policies

Mark Phippard wrote:

> My concern is any link between these scripts and our merge code.  It
> sounds like the plan would be to create these policies and then come
> up with a newmerge command that does not support any of the features
> these policies block?

No, that's not this community's plan.  I evidently don't talk enough; that's a personality problem I have.  I need to communicate more.  How do I explain?  The plan is to improve Subversion's merge capabilities.  We're still working out the details of what that means.

> I honestly do not think these sorts of issues are what most of our
> users are struggling with.  You can do whole branch merges today, you
> can block subtree merges with scripts if that is important etc.  Most
> users seem to learn and adjust to --reintegrate.

It's true we *can* do successful merges now, and much of the time *we* the developers *do* it successfully, but sometimes even we get unexpected results or do what we wouldn't have wished to do.  But *typical* users *often* get it wrong.  Several of us have tried to help real users to unpick the results of where they've merged things around and about and tried to fix it themselves with --record-only and have then called us in, in despair.

It's my goal to help users avoid common pitfalls.

I'm looking at a number of ways to do that.

>  It seems like Julian
> has figured out a way to get rid of the --reintegrate option and if he
> is able to do it while still knowing when to do all the reintegrate
> checks, then subtree merges are no longer an immediate problem.

Yes, I've figured that out *in principle*.  The code I've written so far is just a crude starting point that doesn't yet lift the restrictions that --reintegrate has, and as such is not satisfactory (in fact it makes it *more* confusing because it hides the behaviour difference under a 'symmetric' user interface).

To get symmetric behaviour, the problem is it's freakin' hard to untangle the subtree support and the mixed-rev support and the missing-subtree support and everything from the basic merge algorithm outline, in the existing code.  And the problem is not so much at a coding level, but rather a matter of understanding what, in fact, the semantics are that we're intending to implement currently.

I have so far been dabbing carefully at the existing code, pulling a little more low-level structure into it (such as svn_client__pathrev_t) while extremely carefully preserving the exact behaviour of the code, and I'm doing it that way because I don't understand the intention of the code at sufficient level of detail.  But that's not efficient development.

I am currently thinking it's time to change tack here, stop trying to incrementally change the existing implementation, and instead start figuring out a design and implementation, that we can grow in stages.  Until we're confident it has a promising future, it can stay on a branch or #ifdef'd out or whatever.  I've got to start somewhere.  I can't feasibly reverse-engineer the whole semantics that we've created before I start.  (In this style of open source dev, we often don't have detailed specs for the stuff we create.)  So to get a handle on it I've gone back to the fundamentals of what the merge is meant to do, and am building up from there.  So I've got as far as the theory of how to basically merge a tree (without subtrees, and without a mixed-rev target WC, and so on).  It would be massively constructive and helpful to write some of this as code before and during getting on with figuring out a design for subtrees.  (Actually I have already
 thought and written a start on this, just not in great detail, and I have a theory that a mixed-rev target WC is a very similar issue as subtrees-have-differing-mergeinfo.)

At the same time as having a particular 'symmetric merge' idea, I'd like to take every opportunity to make it easier for others to understand the structure and behaviour of the merge code, and participate in developing it.  So for example I broke the 'reintegrate' API into two parts ('find' and 'do') so that higher level code (including svn but especially GUIs) can get some visibility and a bit more control over what's going on.  And similarly I think we should split the 'merge' API into 'automatic merge' and 'manual merge', because the use cases and the behaviour and the implementation are really quite separate (auto merge should *use* manual merge as a subroutine, not be a slight variant of it).

> Julian also seems to have some nice ideas on improving the output from
> the commands to make the process more understandable.

Yes; I haven't touched on that for a while.

> Where I see users struggling with merges is when it comes to tree
> conflicts.  People rename stuff frequently and then merge in SVN
> becomes nearly unusable.  If we want to really fix merge, I think we
> have to improve how renames are handled.

I totally agree, we really do need to fix that.

> Andy expressed a desire to provide a code review workflow.  With the
> right UI to make the branch creation easy (as well as of course the
> review), I think you could to that today.  There is no reason that
> issues like subtree merges and criss-cross merges etc. should make it
> difficult to provide a feature like that because the UI would steer
> the user away from doing that.  The blocker that does exist today is
> that we do not handle things like renames well.

Yes, agreed: if the branch isn't going to have any complex merging, and is only going to be reintegrated once, then the current merge will handle it.

> Back to your proposal, if users could easily put hooks in place to
> block certain merge features it would make our existing merge easier
> as well.  I guess I am just saying it does not get us off the hook for
> needing to support those features in our merge for the people that do
> want to use them.

Agreed.

- Julian
Received on 2012-04-19 16:56:58 CEST