You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Michael T <ra...@hotmail.com> on 2012/09/19 15:12:50 UTC
Subtree mergeinfo
Hello,
I am aware that this is a much asked question, but since I have nonetheless been
unable to find an answer which quite works for me I will ask it again. Feel
free to point me to a FAQ I have missed by way of answer if appropriate!
We have a large project with multiple branches versioned with Subversion (most
of us are using 1.6 clients at the moment). There is a lot of merging done
between branches, and it has happened on numerous occasions that merging has
been done to branch (or trunk) subtrees which should have been done to the
branch root - in fact, no merge should ever have gone to a subtree. The obvious
result is unwanted mergeinfo changes blossoming through the tree (though even
that is not quite consistent, as people sometimes do not commit mergeinfo
changes on subtrees, and I am sure that a few have been omitted which perhaps
should not have been). I have been looking for a way to clean things up -
basically, to determine for a given branch all changesets which have been merged
to it, to set that information on the branch root and remove (or let Subversion
elide) the information on the subtrees. So far I haven't found a good solution,
and in particular I have been defeated by things like finding 71874-75960 in the
mergeinfo because only change 71874, 75960 and a few in-between applied to a
particular subtree. (Would Subversion 1.6 even handle elision correctly here?)
I would be very grateful for suggestions about how to clean this up as
automatically as possible if this is even feasible!
Many thanks,
Michael
By the way, I am not subscribed to this list, but I will monitor it for a few
weeks for responses.
Re: Subtree mergeinfo
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 05:55:27PM +0200, Michael T wrote:
> Stefan, thanks for your reply. Would a clean-up like I described (gathering
> changesets from all mergeinfo from all subtrees within a branch and setting it
> all on the branch root) be even theoretically correct then, or am I being
> misled by my incomplete understanding of mergeinfo?
This depends on whether the resulting consolidated mergeinfo really
describes all changes that were merged.
You could end up marking revisions that were merged only into a
subtree as having been merged into the entire branch. If this doesn't
reflect what really happened, then the mergeinfo is wrong. The unmerged
changes would be blocked from ever being merged into the parts of
the branch that have not yet received them.
However, sometimes this blocking of changes is exactly what is
desired, see http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.blockchanges
So it all depends on what you really want the mergeinfo to say.
If you don't know what you want it to say and how to get there,
I'd recommend to rely on Subversion to figure it out. After all,
it knows how to interpret subtree mergeinfo, and if you use 1.7
clients you'll only ever see mergeinfo changes happen on nodes
that were actually affected by the merge (unlike with 1.6).
> And would the 71874-75960
> range I mentioned pose a problem for automatic elision, or is it clever enough
> to deal with that?
Depends.
I suspect I didn't explain Subversion's behaviour clearly enough.
Mergeinfo will only be elided from child A/B to parent A if the only
difference between the svn:mergeinfo property is a path-wise adjustment.
The revision ranges must be exactly the same.
For example, this will elide:
A - svn:mergeinfo = (/branches/foo/A:50-60)
A/C - svn:mergeinfo = (/branches/foo/A/C:50-60)
Because the mergeinfo on A/C, path-adjusted to A, matches that of A.
And this won't elide:
A - svn:mergeinfo = (/branches/foo/A:50-60)
A/C - svn:mergeinfo = (/branches/foo/A/C:50-66)
The difference being that revisions 61 to 66 have only been merged
into A/C but not into A.
So elision is not "clever" in any way. All that Subversion does is
checking the two mergeinfo properties for equality after path-wise
adjustment.
Does this clear up your understanding of what you can expect?
RE: Subtree mergeinfo
Posted by Michael T <ra...@hotmail.com>.
Stefan Sperling <stsp <at> elego.de> writes:
> On Wed, Sep 19, 2012 at 01:12:50PM +0000, Michael T wrote:
[...]
> > We have a large project with multiple branches versioned with Subversion
> > (most
> > of us are using 1.6 clients at the moment). There is a lot of merging done
> > between branches, and it has happened on numerous occasions that merging has
> > been done to branch (or trunk) subtrees which should have been done to the
> > branch root - in fact, no merge should ever have gone to a subtree. The
> > obvious
> > result is unwanted mergeinfo changes blossoming through the tree (though
> > even
> > that is not quite consistent, as people sometimes do not commit mergeinfo
> > changes on subtrees, and I am sure that a few have been omitted which
> > perhaps
> > should not have been). I have been looking for a way to clean things up -
> > basically, to determine for a given branch all changesets which have been
> > merged
> > to it, to set that information on the branch root and remove (or let
> > Subversion
> > elide) the information on the subtrees. So far I haven't found a good
> > solution,
> > and in particular I have been defeated by things like finding 71874-75960
> > in the
> > mergeinfo because only change 71874, 75960 and a few in-between applied to a
> > particular subtree. (Would Subversion 1.6 even handle elision correctly
> > here?)
>
> Save yourself the hassle of "cleaning up" mergeinfo. You're likely
> to make things worse unless you're 100% sure how Subversion's internal
> merge-tracking calculations work (in which case you probably would
> not be asking your question in the first place :)
>
> The easiest thing to do is to just leave the mergeinfo alone
> and upgrade all clients to 1.7. This will get rid of superfluous
> mergeinfo modifications during merges. See here for more information:
>
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
>
> Mergeinfo elision is still very basic, even in 1.7. Mergeinfo will only
> ever elide if the revision ranges merged to parent and child match
> exactly, such that the only difference between the svn:mergeinfo
> properties are path differences that disappear when paths in the
> child's mergeinfo are adjusted relative to the parent.
Stefan, thanks for your reply. Would a clean-up like I described (gathering
changesets from all mergeinfo from all subtrees within a branch and setting it
all on the branch root) be even theoretically correct then, or am I being
misled by my incomplete understanding of mergeinfo? And would the 71874-75960
range I mentioned pose a problem for automatic elision, or is it clever enough
to deal with that?
Regards,
Michael
Re: Subtree mergeinfo
Posted by Michael T <ra...@hotmail.com>.
Varnau, Steve (Seaquest R&D <steve.varnau <at> hp.com> writes:
> > -----Original Message-----
[...]
> > From: Stefan Sperling [mailto:stsp <at> elego.de]
> > The easiest thing to do is to just leave the mergeinfo alone and upgrade
> > all clients to 1.7. This will get rid of superfluous mergeinfo
> > modifications during merges. See here for more information:
> > http://subversion.apache.org/docs/release-notes/1.7.html#subtree-
> > mergeinfo-recording
[...]
>
> Good advice. Get users on 1.7 clients! For the cases where a sub-tree was
merged, a relatively safe thing to
> do is to run the same (branches/revs) merges into the root of your trunk.
Assuming the sub-trees already
> picked up the real content changes, these additional merge changes should just
be updating the
> root-level meta-data, and if you get all such branches, then the merge-info
will elide from the sub-tree.
>
> Let the merge command do the dirty work, rather than edit merge-info!
Thank you both! We will presumably all end up on svn 1.7 sooner or later, and
hopefully it (or later versions) will not have too much trouble with the
not-quite-clean state of the mergeinfo. Though I can't say that anyone seems to
be suffering much with 1.5 and 1.6 apart from the annoying proliferation during
merges, so presumably things will only get better!
Regards,
Michael
RE: Subtree mergeinfo
Posted by "Varnau, Steve (Seaquest R&D)" <st...@hp.com>.
> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: Wednesday, September 19, 2012 6:26 AM
> To: Michael T
> Cc: users@subversion.apache.org
> Subject: Re: Subtree mergeinfo
>
> On Wed, Sep 19, 2012 at 01:12:50PM +0000, Michael T wrote:
> > Hello,
> >
> > I am aware that this is a much asked question, but since I have
> > nonetheless been unable to find an answer which quite works for me I
> > will ask it again. Feel free to point me to a FAQ I have missed by
> way of answer if appropriate!
> >
> > We have a large project with multiple branches versioned with
> > Subversion (most of us are using 1.6 clients at the moment). There is
> > a lot of merging done between branches, and it has happened on
> > numerous occasions that merging has been done to branch (or trunk)
> > subtrees which should have been done to the branch root - in fact, no
> > merge should ever have gone to a subtree. The obvious result is
> > unwanted mergeinfo changes blossoming through the tree (though even
> > that is not quite consistent, as people sometimes do not commit
> > mergeinfo changes on subtrees, and I am sure that a few have been
> > omitted which perhaps should not have been). I have been looking for
> > a way to clean things up - basically, to determine for a given branch
> > all changesets which have been merged to it, to set that information
> > on the branch root and remove (or let Subversion
> > elide) the information on the subtrees. So far I haven't found a good
> > solution, and in particular I have been defeated by things like
> > finding 71874-75960 in the mergeinfo because only change 71874, 75960
> > and a few in-between applied to a particular subtree. (Would
> > Subversion 1.6 even handle elision correctly here?)
> >
> > I would be very grateful for suggestions about how to clean this up as
> > automatically as possible if this is even feasible!
> >
> > Many thanks,
> >
> > Michael
> >
> > By the way, I am not subscribed to this list, but I will monitor it
> > for a few weeks for responses.
>
> Save yourself the hassle of "cleaning up" mergeinfo. You're likely to
> make things worse unless you're 100% sure how Subversion's internal
> merge-tracking calculations work (in which case you probably would not
> be asking your question in the first place :)
>
> The easiest thing to do is to just leave the mergeinfo alone and upgrade
> all clients to 1.7. This will get rid of superfluous mergeinfo
> modifications during merges. See here for more information:
> http://subversion.apache.org/docs/release-notes/1.7.html#subtree-
> mergeinfo-recording
>
> Mergeinfo elision is still very basic, even in 1.7. Mergeinfo will only
> ever elide if the revision ranges merged to parent and child match
> exactly, such that the only difference between the svn:mergeinfo
> properties are path differences that disappear when paths in the child's
> mergeinfo are adjusted relative to the parent.
Good advice. Get users on 1.7 clients! For the cases where a sub-tree was merged, a relatively safe thing to do is to run the same (branches/revs) merges into the root of your trunk. Assuming the sub-trees already picked up the real content changes, these additional merge changes should just be updating the root-level meta-data, and if you get all such branches, then the merge-info will elide from the sub-tree.
Let the merge command do the dirty work, rather than edit merge-info!
-Steve
Re: Subtree mergeinfo
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Sep 19, 2012 at 01:12:50PM +0000, Michael T wrote:
> Hello,
>
> I am aware that this is a much asked question, but since I have nonetheless been
> unable to find an answer which quite works for me I will ask it again. Feel
> free to point me to a FAQ I have missed by way of answer if appropriate!
>
> We have a large project with multiple branches versioned with Subversion (most
> of us are using 1.6 clients at the moment). There is a lot of merging done
> between branches, and it has happened on numerous occasions that merging has
> been done to branch (or trunk) subtrees which should have been done to the
> branch root - in fact, no merge should ever have gone to a subtree. The obvious
> result is unwanted mergeinfo changes blossoming through the tree (though even
> that is not quite consistent, as people sometimes do not commit mergeinfo
> changes on subtrees, and I am sure that a few have been omitted which perhaps
> should not have been). I have been looking for a way to clean things up -
> basically, to determine for a given branch all changesets which have been merged
> to it, to set that information on the branch root and remove (or let Subversion
> elide) the information on the subtrees. So far I haven't found a good solution,
> and in particular I have been defeated by things like finding 71874-75960 in the
> mergeinfo because only change 71874, 75960 and a few in-between applied to a
> particular subtree. (Would Subversion 1.6 even handle elision correctly here?)
>
> I would be very grateful for suggestions about how to clean this up as
> automatically as possible if this is even feasible!
>
> Many thanks,
>
> Michael
>
> By the way, I am not subscribed to this list, but I will monitor it for a few
> weeks for responses.
Save yourself the hassle of "cleaning up" mergeinfo. You're likely
to make things worse unless you're 100% sure how Subversion's internal
merge-tracking calculations work (in which case you probably would
not be asking your question in the first place :)
The easiest thing to do is to just leave the mergeinfo alone
and upgrade all clients to 1.7. This will get rid of superfluous
mergeinfo modifications during merges. See here for more information:
http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording
Mergeinfo elision is still very basic, even in 1.7. Mergeinfo will only
ever elide if the revision ranges merged to parent and child match
exactly, such that the only difference between the svn:mergeinfo
properties are path differences that disappear when paths in the
child's mergeinfo are adjusted relative to the parent.