Hi Johan,
On 2016-10-28 16:16, Johan Corveleyn wrote:
On Thu, Oct 27, 2016 at 12:14 PM, Peter van Hoof <p.vanh...@oma.be> wrote:
Hi,
Recently we have been having multiple instances of a problem that doesn't
seem to be going away. The easiest way to see it is to reproduce the
following steps.
1) check out a working copy of one of our development branches:
svn co svn://svn.nublado.org/cloudy/branches/backtrace
Changes from the trunk were last merged to this branch in r11144. This
checkout looks fine and I want to merge the more recent changes from the
trunk. So cd into it and proceed.
2) First take a look at which revisions are eligible:
svn mergeinfo --show-revs eligible ^/trunk .
r11156
r11159
r11160
r11165
r11166
r11167
[ snip... ]
r11337
r11338
r11339
r11340
r11341
This all looks very plausible. The first commit to the trunk after r11144 is
r11156 and the last is r11341. All numbers shown above are correct. I didn't
check all the numbers I cut out, but I assume they are correct as well.
3) All looks fine, so do the merge:
svn merge ^/trunk .
--- Merging r8669 into 'source':
C source/rt_continuum_shield_fcn.cpp
--- Recording mergeinfo for merge of r8667 through r8669 into '.':
U .
--- Recording mergeinfo for merge of r8667 through r8669 into 'source':
U source
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'source/rt_continuum_shield_fcn.cpp'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
(mc) my side of conflict, (tc) their side of conflict,
(s) show all options: ^CSummary of conflicts:
Text conflicts: 1
svn: E155027: Unable to resolve conflicts on
'/home/pvh/noot/backtrace/source/rt_continuum_shield_fcn.cpp'
I hit ^C here. So all of a sudden svn wants to merge r8669, even though it
was not marked as eligible before (and was already merged a long time
ago)...
So what is this? Corrupted information in the svn:mergeinfo propety? A bug
in svn? Or both?
Maybe your branch wasn't really fully synced with ^/trunk up to
r11144, or at least not all mergeinfo related to this sync was fully
committed. I would guess that svn is trying to merge r8669 into
'source', because 'source' has "subtree mergeinfo", and someone didn't
commit the mergeinfo-modification on 'source', way back when he merged
r8669.
The branch was created in r8667 and the first commit to the branch was r8668.
The changes on the trunk (including r8669) were merged in r8689.
I am not even sure how you can commit changes without committing mergeinfo. As
far as I know that is all automatic. To my knowledge I never omitted mergeinfo
and I am pretty sure none of our other users did. I committed r8689 myself, so
the mergeinfo should have been committed too.
I double-checked this and checked out the branch at r8689. This is the result
% svn co svn://svn.nublado.org/cloudy/branches/backtrace@8689
% cd backtrace/
% svn proplist --verbose source/
[...snip...]
/trunk/source:8667-8688
So the revision in question is definitely marked as merged there... This looks
OK, which is also consistent with the fact that subsequent merges from trunk
showed no problems (r8784, r8788, r8815, r11144).
I think that the fragmented mergeinfo is a result of cherry-picking commits on
other branches by other users.
Also, your suggestions do not explain why r8669 wasn't listed in the output of
the "svn mergeinfo --show-revs eligible ^/trunk ." command. If that revision
truly was missing from the mergeinfo, it should have been listed there.
Further down in your output below, I can see that 'source' actually
has subtree mergeinfo (because svn records it there). And as you
probably know: once you have subtree mergeinfo, it *always* has to be
kept up to date (further merges to the parent will automatically
modify any subtree mergeinfo below -- those property mods have to be
committed or mergeinfo will be wrong). So maybe someone forgot to
commit the property modification on 'source' when he merged r8669. You
can probably verify this by checking the exact svn:mergeinfo property
on 'source' (with 'svn propget svn:mergeinfo').
And more importantly how do I fix this? I tried doing this brute-force
approach
Okay, seems like a good technique to fix this, but ...
svn revert -R .
svn merge --record-only -r1:11144 ^/trunk .
--- Merging r2 through r11144 into '.':
G tsuite/auto
G tsuite
G .
--- Recording mergeinfo for merge of r2 through r11144 into '.':
U .
--- Recording mergeinfo for merge of r2 through r11144 into
'data/lamda/masterlist/Lamda.ini':
U data/lamda/masterlist/Lamda.ini
--- Recording mergeinfo for merge of r2 through r11144 into
'data/stout/zn/zn_19/zn_19.coll':
U data/stout/zn/zn_19/zn_19.coll
--- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.coll':
U data/stout/zn/zn_19/zn_19.coll
--- Recording mergeinfo for merge of r2 through r11144 into
'data/stout/zn/zn_19/zn_19.nrg':
U data/stout/zn/zn_19/zn_19.nrg
--- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.nrg':
U data/stout/zn/zn_19/zn_19.nrg
--- Recording mergeinfo for merge of r2 through r11144 into
'data/stout/zn/zn_19/zn_19.tp':
U data/stout/zn/zn_19/zn_19.tp
--- Eliding mergeinfo from 'data/stout/zn/zn_19/zn_19.tp':
U data/stout/zn/zn_19/zn_19.tp
--- Recording mergeinfo for merge of r2 through r11144 into 'source':
U source
--- Recording mergeinfo for merge of r2 through r11144 into 'tsuite':
U tsuite
--- Recording mergeinfo for merge of r2 through r11144 into 'tsuite/auto':
U tsuite/auto
--- Recording mergeinfo for merge of r2 through r11144 into
'tsuite/auto/chianti_all_cool.dat':
U tsuite/auto/chianti_all_cool.dat
--- Recording mergeinfo for merge of r2 through r11144 into
'tsuite/auto/chianti_all_cool.in':
U tsuite/auto/chianti_all_cool.in
Here you should probably perform a commit ("Fixing merginfo of
previous merges" or something like that). Note the lines "Eliding
mergeinfo from 'data/stout/zn/zn_19/zn_19.coll'" and other "Eliding"
lines. This means svn removes subtree mergeinfo there, because it's
redundant (it's the same as what the parent directory says).
OK, this does seem to make a difference and the merge finishes OK, but I do not
understand why. The "svn merge ^/trunk ." command behaved differently before and
after the "svn merge --record-only -r1:11144 ^/trunk ." command. This makes it
clear that it is looking at the mergeinfo records in the local wc (this is the
only thing that changed). But it seems it is also looking at the mergeinfo
records on the server? Why is that? It sounds like a recipe for problems to me
if it is looking for mergeinfo in two different places...
But more importantly. What is the root cause of these problems? The mergeinfo
records look OK to me after r8689 as I showed above. So what convinced svn that
it needed to merge r8669 a second time?
But you leave those property modifications as local mods without
committing, which I think lead to the next problem.
svn merge ^/trunk .
--- Merging r11145 through r11342 into '.':
U data/chianti/masterlist/CloudyChianti.ini
G data/lamda/masterlist/Lamda.ini
U data/stout/c/c_3/c_3.coll
[ snip... ]
C data/stout/zn/zn_19/zn_19.coll
C data/stout/zn/zn_19/zn_19.nrg
C data/stout/zn/zn_19/zn_19.tp
[ snip... ]
G tsuite
G .
--- Recording mergeinfo for merge of r11145 through r11342 into '.':
G .
--- Recording mergeinfo for merge of r11145 through r11342 into
'data/lamda/masterlist/Lamda.ini':
G data/lamda/masterlist/Lamda.ini
--- Recording mergeinfo for merge of r11145 through r11342 into 'source':
G source
--- Recording mergeinfo for merge of r11145 through r11342 into 'tsuite':
G tsuite
--- Recording mergeinfo for merge of r11145 through r11342 into
'tsuite/auto':
G tsuite/auto
--- Recording mergeinfo for merge of r11145 through r11342 into
'tsuite/auto/chianti_all_cool.dat':
G tsuite/auto/chianti_all_cool.dat
--- Recording mergeinfo for merge of r11145 through r11342 into
'tsuite/auto/chianti_all_cool.in':
G tsuite/auto/chianti_all_cool.in
Summary of conflicts:
Property conflicts: 3
Conflict for property 'svn:mergeinfo' discovered on
'data/stout/zn/zn_19/zn_19.coll'.
local delete, incoming edit upon merge
Select: (p) postpone, (mf) my version, (tf) their version,
(dc) display conflict, (e) edit property, (q) quit resolution,
(h) help:
Here I hit ^C again. So this starts promising enough, but then I am faced
with a conflict in the svn:mergeinfo property and I have no idea how to
resolve that.
So, that's a property modification coming in on the node where your
previous step just removed (elided) the mergeinfo. I'm not 100% sure,
but I'd try to commit the previous step first, and then rerun that
last command. Hope that fixes it ...
This kind of problem seems to be spreading to more and more development
branches, so I am really keen on finding a definitive solution for this.
This is starting to interfere quite seriously with our workflow. So any help
is appreciated!
Maybe interesting for you:
https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/svn-mergeinfo-normalizer
This hasn't been released as part of any official svn release yet, but
it seems to work quite well for some people, and could surely use
additional testing :-) (see [1] for another thread mentioning this
tool).
[1] https://svn.haxx.se/users/archive-2016-06/0062.shtml
I will have a look at this as well.
Thanks!
Peter.
