After looking at this some more, we had some svn:mergeinfo properties
that were set at one layer below the branch / trunk levels from some
developers simply working at the wrong level. It spread like a virus
through various branches taken since so I used:
svn propget svn:mergeinfo -R -v svn://mmi-data/node_controller
to go through everywhere that had mergeinfo down one level and then had
to check out just that directory and remove the svn:mergeinfo property
with svn propdel and all is well -- the tool automatically uses the
right set of changes to merge from trunk to branch in my example below.
What is really confusing is that the svn mergeinfo --show-revs eligible
does not actually agree with what the merge does... I view this as a
bug, the mergeinfo could more correctly show before actually doing the
merge that it would want to go back to where the branch was taken and
get into trouble... but it shows things as if they will be merged
correctly, but then the merge command goes back too far and we get tree
conflicts / file conflicts galore...
I'm feeling much better now -- things are cleaned up quite well and I
think we'll be all set.
Hopefully this might help others that could run into similar issues.
Eric Malkowski wrote:
Hi Subverison Users List:
We're using Subversion client and server 1.6.15 exact version: svn,
version 1.6.15 (r1038135)
We are doing the typical trunk and branch development outlined in the
svn book -- i.e. cut a branch, do devel on branch w/ multiple merges
of branch out to trunk, and finally do a re-integrate merge from
branch back to trunk and stop using the branch -- cut another one.
We've been very successful, but made a couple errors on one of our
branches and cannot seem to get back on track -- here's the details:
We cut a branch devel_bugatti at revision r11567, here's the commit
log from branch creation:
emalkowski@eric-lnx:/local/emalkowski/svn_merge$ svn log -v -r11567
svn://mmi-data/node_controller
------------------------------------------------------------------------
r11567 | monorato | 2012-04-26 16:06:04 -0400 (Thu, 26 Apr 2012) | 1 line
Changed paths:
A /node_controller/branches/devel_bugatti (from
/node_controller/trunk:11566)
So devel continued on branch and trunk and we did mess up on some
merges from trunk to branch where the error was that the svn:mergeinfo
property was NOT committed on two trunk to branch merges. So it went
as follows:
- One merge of trunk to branch done correct where the mergeinfo was
committed after the merge.
- Second merge trunk to branch, developer committed all merged files,
but missed commit of svn:mergeinfo prop update on devel_bugatti dir
- Third merge of trunk to branch, developer missed svn:mergeinfo
again, didn't have any real problems with conflicts and branch devel
is now done.
I attempted a merge from trunk to branch to prepare for branch retire
and it keeps merging from branch creation r11567 to the HEAD of trunk
-- this results in tree conflicts for files/dirs added on trunk, (that
live on branch due to previous untracked merges w/o mergeinfo) and it
leads to file conflicts / trying to merge more than it should.
So to try and fix this, I did a propedit on the dir devel_bugatti with
the mergeinfo property to set the range from 11567 to 12199 which by
examining logs from trunk and branch 12199 is the last thing committed
to the trunk that was already merged to the branch. The idea is to
merge 12199 to HEAD changes on trunk to branch to only pick up what's
changed on trunk since most recent merge that missed mergeinfo... The
commands that show what is merged from trunk to branch already and
what is eligible look totally right (evidence changing mergeinfo range
to 11567-12199 should work) -- but when doing the merge, it still goes
back to when the branch was created and doesn't seem to use the
svn:merginfo data!!! Anyone have any idea why the merge command would
behave different than what eligible says would be merged? I'm going
to start losing sleep over this any ideas greatly appreciated:
emalkowski@eric-lnx:/local/emalkowski/svn_merge/devel_bugatti$ svn
proplist -v .
Properties on '.':
svn:mergeinfo
/node_controller/branches/devel:1321-1564
/node_controller/branches/devel_delorean:11566-12027
/node_controller/branches/devel_ducati:1566-11563
/node_controller/branches/devel_emalkowski:1326-1449
/node_controller/branches/devel_monorato:1324-1451
/node_controller/branches/devel_rblack:1325-1456
/node_controller/branches/devel_rblack_bugatti_mpid:12091-12147
/node_controller/trunk:11567-12199
The last line is the interesting one that is tracking trunk -- by the
way, before hand editing it, the 2nd number in the range was 12149
which was the committed mergeinfo from the very first trunk to branch
merge before the two messed up ones were done (and mergeinfo stayed at
12149).
emalkowski@eric-lnx:/local/emalkowski/svn_merge/devel_bugatti$ svn
mergeinfo svn://mmi-data/node_controller/trunk
r11652
r11799
r11800
r12028
r12029
r12098
r12112
r12113
r12140
r12156
r12199
This looks right -- all stuff merged from from trunk to branch that's
done already, branch builds right etc., looking at what another merge
from trunk to branch should get us for revs from the trunk to bring out:
emalkowski@eric-lnx:/local/emalkowski/svn_merge/devel_bugatti$ svn
mergeinfo svn://mmi-data/node_controller/trunk --show-revs eligible
r12317
r12326
r12410
r12531
r12610
r12765
r12802
r13233
r13253
r13254
So we have 12317-13254 that are all of the stuff we want from the
trunk to be brought out to the branch. Here we go with the merge and
the line "Merging r11567 through r13260" is wrong!!! it should be
merging some revision > r12199 to r13254. r11567 is back to start of
branch and the tree and file conflicts ensue and I'm up at night!!!
emalkowski@eric-lnx:/local/emalkowski/svn_merge/devel_bugatti$ svn
merge svn://mmi-data/node_controller/trunk
--- Merging r11567 through r13260 into 'buildroot':
Now I can go and force it to merge a specific range since I know which
things should be merged from analyzing logs... and I can do that (and
tried it and no dir conflicts, it did reasonable file work) and commit
and let the tool update the mergeinfo for future stuff... but this
scares me that my eventual re-intregrate merge from branch to trunk
will be a disaster or even additional trunk to branch merges after my
forced range of changes to merge will be a problem. Does the tool do
something where it flags hand edited mergeinfo as invalid or something
and hence the reason is just thinks the trunk has never been merged to
the branch and goes back to r11567 ??? I've looked at this carefully
and I'm stumped.
Thanks so much for any help.
--
Eric Malkowski
Linux guy since kernel 1.0.9 in 1994
