Is it accurate then to say that Subversion may generate explicit mergeinfo whenever it decides that there is something useful to record about the set of revisions that contributed to a given node, and that svn:mergeinfo properties may appear in subnodes as part of normal Subversion merging bookkeeping, and this doesn't imply lack of a full root->root merge or other user shenanigans?
I appreciate your time on this. Thanks, --Pete On Tue, Mar 17, 2015 at 8:58 AM, Pete Harlan <pchpubli...@gmail.com> wrote: > On Mon, Mar 16, 2015 at 6:08 PM, Branko Čibej <br...@wandisco.com> wrote: >>>> 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. >> >> "Conflict" is a transient property of the working copy. "Mergeinfo" is >> an attribute of the repository and is a permanent record. In most >> conflict cases there are at least two ways to resolve the conflict, each >> of which could produce a different answer to the question "what was merged?" > > The user decides "what was merged" by passing arguments to the "svn > merge" command. Conflict resolution determines what files constitute > the correct result of that merge. > > The user decides what "svn merge X Y" looks like, and only they can be > the authority on that. It may involve fixing semantic conflicts, it > may involve throwing away half the tree: that's up to the user. But > it has no bearing on whether the result is to be considered a merge > from X to Y. That is the meaning of "svn merge X Y". > > Conflicts are Subversion saying "I need help merging these two paths; > here's how I'm confused". Solving that confusion does not change the > answer to the question "what was merged?" > >>> 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. >> >> See above re ideal world ... currently it's far from ideal. One could >> argue that it's better to improve some cases, rather than hope to get >> them all covered in one go. >> >> In the case we're debating: if a normal conflict resolution leaves >> unnecessary (essentially duplicate) mergeinfo, that's clearly a bug. If >> it doesn't, then it's working correctly, even if not as expected, IMO. > > We seem to disagree on what mergeinfo is for. Here's a case where I > want subtree mergeinfo: > > 1. Branch X merges from trunk. All mergeinfo was at root of X prior > to the merge, and it is so after the merge. > 2. A subtree of X merges from a subtree of branch Y. Now there's a > mergeinfo at the root of X and at the root of the subtree. > 3. Branch X merges from trunk again. We still need mergeinfo at X and > at the subtree, because the subtree contains revisions (from Y) that X > does not. > 4. Branch X merges from branch Y. Subversion uses its extra info at > the root of the subtree to help with the merge. > > At the conclusion of #4, Subversion will probably still have mergeinfo > at the root of X and at the root of X's subtree; the subtree mergeinfo > property is redundant now because both X and the subtree include all > the same revisions of the trunk and of branch Y. > > In an ideal world, Subversion could remove the now-redundant subtree > mergeinfo after #4; I'm not asking for that. But it would be a *bug* > for it to have separate subtree info after #1. That it does, is what > I'm reporting. > > In case this helps, here's what's motivating my report. We have a > policy against subtree merges: users are only allowed to commit merges > performed between branch/trunk roots. We enforce that policy by > rejecting commits that add svn:mergeinfo properties to interior nodes. > In my understanding, this is a correct way to enforce the policy, > because subtree merges are what interior svn:mergeinfo properties are > for. > > --Pete
