You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nicholas Curry <Ni...@cofunds.co.uk> on 2009/04/07 14:20:08 UTC
How is mergeinfo calculated for hierarchies?
Hi,
I just wanted to check my assumptions on how the svn:mergeinfo property
works:
* 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
/branches/branchB/folder1.
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)?
Thanks,
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@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.
**************************************************************************
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1577892
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: How is mergeinfo calculated for hierarchies?
Posted by Nicholas Curry <Ni...@cofunds.co.uk>.
Hi Tyler,
Thanks a lot for taking the time to go through my message - I sure am
sorry to hear that no-one knows how mergeinfo works (a little bait to
see if I can get anyone who does to take an interest in explaining...)
I'll go through the article you mention and compare it to what I've
observed so far!
Cheers,
Nick
-----Original Message-----
From: Tyler Roscoe [mailto:tyler@cryptio.net]
Sent: 07 April 2009 18:14
To: Nicholas Curry
Cc: users@subversion.tigris.org
Subject: Re: How is mergeinfo calculated for hierarchies?
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
********************************************************
This e-mail has been swept for viruses by Cofunds.
For more information on this service, please
contact the IT Service Desk on Ext: 7060 or itservicedesk@cofunds.co.uk.
********************************************************
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@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.
**************************************************************************
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1592733
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: How is mergeinfo calculated for hierarchies?
Posted by Tyler Roscoe <ty...@cryptio.net>.
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