Re: Implicit keep-alive after reintegrate merge
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Jan 2012 14:38:48 +0000 (GMT)
Branko Čibej wrote:
> On 18.01.2012 23:37, Julian Foad wrote:
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
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
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.
> I suspect that the real trick is in finding the correct common ancestor
This is an archived mail posted to the Subversion Dev mailing list.