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
