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_at_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_at_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_at_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_at_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_at_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
>
>
>
>
Received on 2012-12-20 21:47:23 CET