On Mon, Mar 16, 2015 at 12:31 PM, Branko Čibej <br...@wandisco.com> wrote: >> A colleague argued that creating the mergeinfo for a subtree in this >> case (root->root merge) is a simple bug because mergeinfo says what >> inputs were considered to come up with the result, not just those that >> were used. >> >> 1. If the resulting mergeinfo is the same as for root then it's >> unnecessary, so the bug is that it is explicitly listed at all. >> >> 2. If the resulting mergeinfo is different than then root one then >> it's incorrect, because it's claiming that the subtree working copy >> represents the merge of a different set of branches and revisions than >> the root working copy it's included within. >> >> In other words, it would always be wrong for a merge to introduce >> explicit mergeinfo for a subtree of the merge point. >> >> This implies that the fix wouldn't be to change how resolve works, it >> would be for "svn merge" to not create the property on the subtree in >> the first place. >> >> What do you think? > > In an ideal world, you colleague's argument would be wrong: the merge > should record what was actually merged, not what the merge command > intended. So, in cases as the one that started this discussion — when > part of the tree cannot be merged due to a conflict — the mergeinfo > should report that. Removing that not from mergeinfo should be an > integral part of the conflict resolution. > > In other words, mergeinfo should always show what /actually/ happened, > not what we wish had happened. > > -- Brane
Doesn't the conflicted state of a path already indicate what actually happened? There can be no mistake about those portions of the merge being incomplete. If the svn developers do decide that introducing mergeinfo for [some? why not all?] conflicted paths is the correct scenario, I would think that that shouldn't be done until resolve knows how to clean it up. Pete
