RE: Question about mergeinfo
From: Bob Archer <Bob.Archer_at_amsi.com>
Date: Fri, 6 Aug 2010 11:20:57 -0400
> > Of course, --ignore-ancestry will also, well ignore ancestry,
I think the best bet is to quote from the redbook:
Using --ignore-ancestry
Noticing or Ignoring Ancestry
When conversing with a Subversion developer, you might very likely hear reference to the term ancestry. This word is used to describe the relationship between two objects in a repository: if they're related to each other, one object is said to be an ancestor of the other.
For example, suppose you commit revision 100, which includes a change to a file foo.c. Then foo.c_at_99 is an "ancestor" of foo.c_at_100. On the other hand, suppose you commit the deletion of foo.c in revision 101, and then add a new file by the same name in revision 102. In this case, foo.c_at_99 and foo.c_at_102 may appear to be related (they have the same path), but in fact are completely different objects in the repository. They share no history or "ancestry."
The reason for bringing this up is to point out an important difference between svn diff and svn merge. The former command ignores ancestry, while the latter command is quite sensitive to it. For example, if you asked svn diff to compare revisions 99 and 102 of foo.c, you would see line-based diffs; the diff command is blindly comparing two paths. But if you asked svn merge to compare the same two objects, it would notice that they're unrelated and first attempt to delete the old file, then add the new file; the output would indicate a deletion followed by an add:
D foo.c
--- It goes on to talk about merging unrelated trees which is when you would probably want to use --ignore-ancestry. BObReceived on 2010-08-06 17:21:37 CEST |
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.