Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MergeInfoDisplay" page has been changed by JulianFoad: http://wiki.apache.org/subversion/MergeInfoDisplay?action=diff&rev1=3&rev2=4 Implement these measures by building onto Subversion’s existing library API, command-line UI, client-server interface and/or any other suitable level. If this requires knowledge of the user’s branching model and rules, provide a simple way to configure this and provide one or more typical configurations. A pre-requisite for designing and implementing such guidance is a clear statement of what merging scenarios Subversion supports. See the document [[https://docs.google.com/document/d/1wUCZOEywizf88BGjQn8RWqZ3reOoQXEsOnMOybK6qpI/edit?hl=en_GB|Supported Merge Scenarios]]. + + == Pitfalls & Quick Fixes == + The aim here is to list things that users might do in Subversion that are not Right — that is, things that will not lead to consistent and useful results in merging later on — that could be avoided by some high-level checks or by better informing the user. + + Using branch naming terminology from the ‘Terminology’ section below. + + * On a ''feature branch'', attempting to merge to ''parent'' without “--reintegrate” is wrong, (except perhaps for a cherry-pick, and that would be unusual). Catch this case. Possibly with hook script? Need awareness of what kind of branch ‘this’ is. + * Catch other cases from the ‘Branching and Merging Policy’ section below. + * On any branch, a reverse-merge of a merge in this branch’s own history will not do what we expect, I think, in that it won’t be recorded. The correctness of that depends on whether the user’s intention was to temporarily roll back that merge (but still intend to do it later) or to record that undoing as a deliberate and permanent change that should be carried through to other branches. The other way to roll back a merge is to reverse-merge the original changes from the source branch. That gives the corresponding mergeinfo update, but it has at least two significant drawbacks: it will hit all the conflicts that were hit and resolved when it was merged the first time; and the exact reverse merge to perform is non-obvious unless the original merge was from a trivial source revision-range. + * If you cherry-pick from a ''feature branch'' to its trunk, that’s valid for an original change but not if the change that you’re picking is itself a merge (at least if it’s a merge from trunk). We can detect this by seeing whether that change includes a mergeinfo diff. + + '''Common misconceptions''' + + * That merging from branch A to branch B will make B look like A. + * A client said “I merged A to B, then modified B, and now need to revert the change on B; maybe I could do that by merging A to B again”. In that case, I think the merge from A to B was a “reintegrate” which does indeed pretty much make B look like A. (Source: WD support ticket #3013.) + + * To help avoid this, ‘merge’ should display messages about what it’s doing, using terminology that makes clear that ''changes'' are being merged rather than ''state''. + + * Not realizing that to reintegrate “my” branch I first have to obtain and be “in” a WC of the ''parent'' branch. + * It’s easy to think “a catch-up merge pulls changes from the parent, so a reintegrate will ''push'' changes to the parent”. + * In a typical recommended work flow when the branch is fully caught up and the parent branch is not too busy, a reintegrate will not have any conflicts nor need any further testing, so there should is no logical reason (in those cases) for the user to expect that a WC of the target (parent) branch should be needed. == Reporting -- What “svn merge” Should Say == “svn merge” should first of all give a summary of what it is about to do, using words that make sense to the user. Consider stopping to ask for confirmation (unless --no-interactive). Some of the output should be a summary of what is calculated as needing to be merged. That is not only a chance to check the user’s expectation, but in a merge that involves significant calculating of source revisions, it is also a chance for the user to see that Subversion has been doing something useful up to this point and is about to move on to the next stage of actually merging those revisions.
