Stefan Fuhrmann wrote:
> (2) Modified merges.
> In case of textual conflicts, users will usually resolve them
> before committing the merge result. Depending on policies,
> a user may even need to modify textually successful merges
> to e.g. fix a broken build before the merge may be committed.
>
> The problem is that SVN will not record the difference between
> the merge result and the combined change that eventually
> get committed. This information is not lost because the system
> could redo the merge and diff the result against the committed
> change. But it is expensive to get that information.
Please read the "Identifying Logical Changes vs. Commits" section on the Wiki:
<wiki.apache.org/subversion/SupportedMergeScenarios#Identifying_Logical_Changes_vs._Commits>
I regard the editing of a merge result to be an *essential* and
*inherent* part of merging a logical change to another branch. Strictly
speaking, there is no canonical "merge result", there is only a combination of the user and his/her chosen tools(s) helping him/her to do the merge. For example, "the result" differs depending on whether the user has chosen kdiff3 or Subversion's built-in diff3.
> To me, this has been even more annoying than tree-conflicts
> due its consequences. SVN pretends that the commit contained
> just the result of automatic merge and the user's input is being
> ignored. If you try to merge the result back to the initial merge's
> source, you are likely to get the same conflicts that have
> already been resolved because that very resolution will not be
> included in the merge.
No, when you say "try to merge the result back", I think you're mixing up different issues.
> From discussions with Julian, it seems that Symmetric Merge
> could already do better while still "ignoring" the user's change.
>
> I realize that a proper fix to this situation is difficult because
> a single merge request may be broken down into multiple
> ranges being merged sequentially. After each of them, there
> may be a conflict being resolved manually etc. OTOH, there
> is great potential in improving our merge performance
> because differentiating between merge result and manual
> intervention increases the amount of information available
> to automatic conflict resolution / prevention.
This point of view has been stated many times on the dev list but I say it's bogus. Please try to figure out how that approach could work (at a high level) if you think it could.
- Julian
Received on 2012-04-25 13:01:52 CEST