Version Control with Subversion - Login

Branching and MergingWhile the first example shows the “full” syntax of svn merge, it needs to be used verycarefully; it can result in merges which do not record any svn:mergeinfo metadata at all.The next section talks a bit more about this.Merges Without MergeinfoSubversion tries to generate merge metadata whenever it can, to make future invocationsof svn merge smarter. There are still situations, however, where svn:mergeinfo data isnot created or changed. Remember to be a bit wary of these scenarios:Merging unrelated sourcesIf you ask svn merge to compare two URLs that aren't related to each other, a patchwill still be generated and applied to your working copy, but no merging metadata willbe created. There's no common history between the two sources, and future “smart”merges depend on that common history.Merging from foreign repositoriesWhile it's possible to run a command such as svn merge -r 100:200 http://svn.foreignproject.com/repos/trunk,the resultant patch will also lackany historical merge metadata. At time of this writing, Subversion has no way of representingdifferent repository URLs within the svn:mergeinfo property.Using --ignore-ancestryIf this option is passed to svn merge, it causes the merging logic to mindlessly generatedifferences the same way that svn diff does, ignoring any historical relationships.We discuss this later in the chapter in the section called “Noticing or IgnoringAncestry”.Applying reverse merges to a target's natural historyEarlier in this chapter (the section called “Undoing Changes”) we discussed how to usesvn merge to apply a “reverse patch” as a way of rolling back changes. If this techniqueis used to undo a change to an object's personal history (e.g., commit r5 to thetrunk, then immediately roll back r5 using svn merge . -c -5), this sort of mergedoesn't affect the recorded mergeinfo. 5More on Merge ConflictsJust like the svn update command, svn merge applies changes to your working copy.And therefore it's also capable of creating conflicts. The conflicts produced by svn merge,however, are sometimes different, and this section explains those differences.To begin with, assume that your working copy has no local edits. When you svn update toa particular revision, the changes sent by the server will always apply “cleanly” to yourworking copy. The server produces the delta by comparing two trees: a virtual snapshot ofyour working copy, and the revision tree you're interested in. Because the left hand side ofthe comparison is exactly equal to what you already have, the delta is guaranteed to correctlyconvert your working copy into the right hand tree.But svn merge has no such guarantees and can be much more chaotic: the advanceduser can ask the server to compare any two trees at all, even ones that are unrelated tothe working copy! This means there's large potential for human error. Users will sometimescompare the wrong two trees, creating a delta that doesn't apply cleanly. svn merge willdo its best to apply as much of the delta as possible, but some parts may be impossible.Just as the Unix patch command sometimes complains about “failed hunks,” svn mergewill similarly complain about “skipped targets”:5 Interestingly, after rolling back a revision like this, we wouldn't be able to reapply the revision using svn merge. -c 5, since the mergeinfo would already list r5 as being applied. We would have to use the --ignore-ancestry option to make the merge command ignore the existing mergeinfo!103