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
