Subversion tries to generate merge metadata whenever it can, to
make future invocations of svn
merge smarter. There are still situations, however,
where svn:mergeinfo
data is
not created or changed. Remember to be a bit wary of these
scenarios:
If you ask svn merge to compare two URLs that aren’t related to each other, a patch will still be generated and applied to your working copy, but no merging metadata will be created. There’s no common history between the two sources, and future “smart” merges depend on that common history.
While it’s possible to run a command such as svn
merge -r 100:200
,
the resultant patch will also lack any historical merge metadata.
At time of this writing, Subversion has no way of representing
different repository URLs within the http://svn.foreignproject.com/repos/trunk
svn:mergeinfo
property.
--ignore-ancestry
If this option is passed to svn merge, it causes the merging logic to mindlessly generate differences the same way that svn diff does, ignoring any historical relationships. We discuss this later in the chapter in Noticing or Ignoring Ancestry.
Earlier in this chapter (Undoing Changes), we discussed how
to use svn merge to apply a
“reverse patch” as a way of rolling back changes. If
this technique is used to undo a change to an object’s personal
history (e.g., commit r5 to the trunk, then immediately roll back
r5 using svn merge . -c -5
), this sort of merge
doesn’t affect the recorded mergeinfo.[23]
[23] 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!