Hi Nicholas,
I found this article very helpful:
http://www.collab.net/community/subversion/articles/merge-info.html
plus of course the chapter in the svn book about merging.
I'm not at all an expert on how mergeinfo works, but I'll take a whack
at your questions:
On Tue, Apr 07, 2009 at 03:20:08PM +0100, Nicholas Curry wrote:
> * the mergeinfo is what allows SVN to keep track of what files need
> merging and which don't when repeatedly merging from one branch to
> another. So for instance, if I try to merge /branches/branchA into
> /branches/branchB 3 times in a row without any changes being committed
> to either branch in between merges, only the first will result in any
> changes, including svn properties (assuming that there are changes in
> /branches/branchA that are eligible for merging into /branches/branchB
> at the time of the first merge.)
Correct.
> * mergeinfo is inherited; so:
> * if I merge /branches/branchA into /branches/branchB, and then
> merge /branches/branchB/file1 into /branches/branchC, SVN won't attempt
> to re-merge file1 when I merge branchA into branchC.
I think this will work but I would test it before relying on it.
> * if I merge /branches/branchA into /branches/branchB, the mergeinfo
> is stored at the /branches/branchA (top) level rather than for each
> nested file/folder
Correct.
> * if a /branches/branchA/folder1/file1 has a mergeinfo property for a
> specific branch and revision range (e.g.
> "/branches/branchB/folder1/file1:1-5"), and then /branches/branchB is
> merged into /branches/branchA, the mergeinfo properties will be modified
> for both /branches/branchA (at the top level) and
> /branches/branchA/folder1/file1 (for nested files with existing
> mergeinfo properties). SVN doesn't attempt to 'automatically' work out
> the differences between mergeinfo properties in nested hierarchies to
> get rid of any redundant information.
My understanding is that Subversion is supposed to try and "elide"
unnecessary mergeinfo when possible.
> * when the inherited mergeinfo is calculated, SVN takes into account the
> mergeinfo of parent folders that are outside of the specified hierarchy
> into account. So for instance, if I merge /branches/branchA into
> /branches/branchB (revisions 1-6), and then later try to merge
> /branches/branchA/folder1 into /branches/branchB/folder1 (revisions
> 1-10), SVN won't try to re-merge revisions 1-6 from
> /branches/branchA/folder1 into /branches/branchB/folder1.
This is what I think is supposed to happen, but I the behavior I saw was
different. I don't know if I'm just unpopular or what, but when I asked
a similar question I got no response, so my impression is that no one
understands how mergeinfo inheritance works :).
http://svn.haxx.se/users/archive-2009-03/0444.shtml
http://svn.haxx.se/dev/archive-2009-03/0597.shtml
> * Conversely, SVN also considers the mergeinfo for nested files/folders
> when performing a merge; so if I merge /branches/branchA/folder1 into
> /branches/branchB/folder1 (revisions 5-10), and later try to merge
> /branches/branchA into /branches/branchB (revisions 5-20), SVN won't try
> to re-merge revisions 5-10 from /branches/branchA/folder1 into
> /branches/branchB/folder1.
I think this is correct.
tyler
Received on 2009-04-07 19:14:40 CEST