Re: Implicit keep-alive after reintegrate merge

Branko Čibej wrote:

> On 18.01.2012 23:37, Julian Foad wrote:
>> [...] 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).

Hi Brane.  Interesting thoughts, even before you hand-waved away the renames!

We seem to have very different views of merge tracking.  I invite you to read a bit about my line of thinking in the "Identifying Logical Changes vs. Commits" section of <http://wiki.apache.org/subversion/SupportedMergeScenarios>.

> 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.

Not at all.  In general, whenever a change is merged to another branch, there will be some conflict resolution to make it fit the physical (e.g. source code syntax) and logical (e.g. functional or documentation) requirements of the target branch.  But Subversion records that you've merged "r8", and I believe that means you've merged the *logical substance* of r8.  By no means are all bets off after that; indeed, that is exactly the information we want to track.

Furthermore, it is fundamental to (at least this model of) merge tracking that the user only modifies the merge-commit in ways that preserve the logical substance of the change.  That is what I call "conflict resolution" in its full generality of resolving both the conflicts that Subversion happens to detect (which depends on what diff3 plug-in you're using) and those (functional, whatever) conflicts that it doesn't detect for you.

If a user chooses to edit the merge result so as to introduce another logical change, or to undo part of the logical change, then that isn't going to be recorded and the user can't expect Subversion to help them track such a change.  (If this concept is unfamiliar it may need a bit more explanation with examples to make it clear.)

> 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 have to ask, are you writing from a point of view of having a mental model in which simply analyzing diffs *could* achieve the requisite tracking results?  Because I can't begin to see how.

- Julian

> 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 15:39:27 CET