I'm searching through a particularly gnarly set of older revisions in one of our repositories, trying to figure out what happened with a couple of supposed merges.
When I look at one of the revisions in the target branch, it shows me content that's exactly the same as a revision on the source branch (trust me, I checked the diffs, too):
$ svn --log --verbose --use-merge-history --revision 100 ^/target
------------------------------------------------------------------------
r100 | <author> | <date> | 1 line
Changed paths:
A /path/to/new/file
------------------------------------------------------------------------
But, there's something missing. There's no mergeinfo property change recorded anywhere, right? So it can't be a merge, as best I understand it. Maybe the author hand edited the file?
I double checked what Subversion thought were eligible revisions:
$ svn mergeinfo --show-revs eligible ^/source ^/target | grep 100
Nothing! Subversion thinks the revision has been merged despite the lack of mergeinfo.
$ svn mergeinfo --show-revs merged ^/source ^/target | grep 100
r100
Is that possible? How?
I read the CollabNet article and the Svn Book section on missing mergeinfo.
Oops, there actually is svn:mergeinfo
property as far as I can tell now. I don't remember whether svn log
prints property-only changes (it has to), try running svn log --verbose
or run svn propget svn:mergeinfo --verbose
against the ^/target
.
Read SVNBook | Merges Without Mergeinfo.
BTW, don't forget that mergeinfo was introduced in Subversion 1.5. So if the merge happened with older Subversion version, there is a chance that this is why svn:mergeinfo
property is missing.
And yes, the commit author out of ignorance could hand edit the file to make the commit look like a merge.