[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

How is mergeinfo calculated for hierarchies?

From: Nicholas Curry <Nicholas.Curry_at_cofunds.co.uk>
Date: Tue, 7 Apr 2009 15:20:08 +0100


I just wanted to check my assumptions on how the svn:mergeinfo property

* 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.)

* 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.
    * 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

* 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.

* 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.

* 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

These assumptions are based on either observations or expectations of
how things should work; would anyone be able to confirm whether they are
correct (either based on similar observations, or based on knowledge of
how SVN works)?

Nick C

Cofunds Limited, 1st Floor, 1 Minster Court, Mincing Lane,
London EC3R 7AA. Registered in England and Wales
No 3965289. Authorised and regulated by Financial Services Authority. Phone: 0845 604 4001, or visit our website at www.cofunds.co.uk.
Telephone calls may be recorded for monitoring purposes.
The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. Any unauthorised use, dissemination of the information, or copying of this message is prohibited. If you are not the addressee, or believe this email to have been sent in error, please notify security_at_cofunds.co.uk immediately and delete this message.
Although this e-mail and any attachments are believed to be free of any virus, or other defect which might affect any computer or system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Cofunds for any loss or damage from receipt or use thereof.
This email does not create or vary any contractual obligations between Cofunds Limited and the addressee. Any views or opinions are solely those of the author and do not necessarily represent those of Cofunds Limited.
Those communicating with us by electronic mail will be deemed to have accepted the risks associated with interception, amendment, loss and late or incomplete delivery. They will also be deemed to have consented to our monitoring of such communications.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-07 16:21:37 CEST

This is an archived mail posted to the Subversion Users mailing list.