On 18.01.2012 23:37, Julian Foad wrote:
> Branko Čibej wrote:
>
>> On 18.01.2012 14:45, Julian Foad wrote:
>>>> A_at_1---r4---r5---r6---r7----------------r11----------->
>>>> |\ ^ |
>>>> | \ | |
>>>> | \ reintegrate |
>>>> | V | |
>>>> | A_COPY_2-----------------r9---r10--- |
>>>> | ^ sync merge
>>>> | / |
>>>> | cherry-pick merge of r8 |
>>>> V / V
>>>> A_COPY-------------------r8------------------------->
>>> Thanks for this good example of a more complex use case. I've included
>>> it in <http://wiki.apache.org/subversion/KeepingReintegratedBranchAlive>
>>> and written up a discussion of the options there.
>>>
>>> What do we want in this case? The options are basically:
> (To be sure we're talking about the same thing, here I'm talking about how Subversion decides whether to merge the change "r11" from A onto A_COPY.)
>
>>> (1) try to merge (as we do now), despite knowing it will conflict;
>> Actually, you know that it will not conflict, unless r9 or r10
>> introduced changes in the same place as r8. Otherwise the code is the
>> same and diff3 should skip that part, yes?
> No; I mean in general it will conflict. Yes there are certain simple changes that the three-way text merge function will detect as "looks like that change has already been made here" and auto-resolve it as a no-op, but that's beside the point.
I don't think it's beside the point. Mergeinfo can only give you a hint
about node-level conflicts some of the time, and you still have to be
careful about when to believe it. But "svn merge" isn't really about
nodes, it's about textual changes -- at least as far as the user is
concerned (and I'm carefully hand-waving away tracking renames). So in
the end, you have to rely on textual diffs in order to guesstimate what
actually happened. Even looking at your cherry-pick merge of r8 in the
diagram example above, all bets are off if only half of the r8 change to
A was actually committed in r9 (in other words, if the user edited the
result before committing the merge).
It's easy to tell the users "don't do that", but not really realistic.
After all, this happens every time you have to manually resolve a text
conflict.
Instead of trying to invent ways to not make current reintegrate suck
rocks, I'd suggest taking a look at how other tools handle such repeated
merges between branches. Specifically, since git afficionados have so
much to say about how good merging in git is, especially compared to
Subversion, I'd be really interested to see if -- when you get down to
cases -- it can actually do anything that analyzing the diff3 results
(or, more likely, using diff4) can't already do.
I suspect that the real trick is in finding the correct common ancestor
for diff3, and properly pruning the diff3 result, rather than hoping
that merginfo will correctly tell you which cherry-picked revisions to
skip. Because it certainly won't and can't, in general. What it /can/
tell you is which ones to be extra careful about.
-- Brane
Received on 2012-01-19 01:33:39 CET