Hi Peter,
On 11/3/2016 12:49, Peter van Hoof wrote:
> Hi Johan,
>
> On 2016-10-28 16:16, Johan Corveleyn wrote:
>> On Thu, Oct 27, 2016 at 12:14 PM, Peter van Hoof <p.vanhoof_at_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_at_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.
Since I've been pointed to this thread by Daniel Shahaf, here's a few
things to point out the situation specific to your repository. Johan and
Stefan already provided you all the necessary general details, I take it.
Since you suggested you have the same issue in other branches, maybe the
svn normalizer tool pointed to by Johan might be of use to you (but bare
in mind it's quite experimental, since it hasn't been thoroughly tested
by a broad user base yet). If you have a Windows machine to play with, a
developer snapshot containing the precompiled tool is available here:
http://www.luke1410.de/typo3/index.php?id=97
"MaxSVN trunk-dev-r1743999-1 (Zip)" is the version you might wanna try (
http://www.luke1410.de/typo3/fileadmin/user_upload/maxsvn_trunk-dev-r1743999-1.zip
).
Back to your particular case:
So in your case you have multiple mergeinfo records (note: based on your
report here, I only checked backtrace, backtrace/source,
backtrace/data/stdout/zn/zn_19 --- there might be more).
List of relevant mergeinfo entries:
branch-related mergeinfo was omitted in the following list, since it's
not relevant for the case discussed here:
backtrace:
/trunk:8667-11143
/trunk/data/lamda/masterlist:7854-7904
backtrace/source:
*no mergeinfo record for trunk*
backtrace/data/stdout/zn/zn_19/zn_19.coll:
/trunk/data/lamda/masterlist/data/stout/zn/zn_19/zn_19.coll:7854-7904
/trunk/data/stout/zn/zn_19/zn_19.coll:8667-8814,9296-11143
backtrace/data/stdout/zn/zn_19/zn19.nrg:
/trunk/data/lamda/masterlist/data/stout/zn/zn_19/zn_19.nrg:7854-7904
/trunk/data/stout/zn/zn_19/zn_19.nrg:8667-8814,9296-11143
backtrace/data/stdout/zn/zn_19/zn19.tp:
/trunk/data/lamda/masterlist/data/stout/zn/zn_19/zn_19.tp:7854-7904
/trunk/data/stout/zn/zn_19/zn_19.tp:8667-8814,9296-11143
As guessed correctly by Johan, backtrace/source contains a list of
mergeinfos, but misses all the revisions from trunk. Therefore, svn
reads this as nothing from trunk/source was merged into backtrace/source
yet. The approach using --record-only is one way to correct this, as it
would add the missing mergeinfo.
Digging into the history of the repository shows that in revision 8026
on trunk the HfsLines branch was reintegrated. As part of this
reintegration the following merge info made it into the trunk root folder:
/trunk/data/lamda/masterlist:7854-7904
/branches/stout2/data/lamda/masterlist:7769-7853
Presumably something was merged incorrectly on the reintegrated HfsLines
branch. One possible explanation would be that someone wanted to merge
only part of revisions 7854-7905 and 7769-7853 but set the incorrect
destination path for the merge command as in:
svn merge [URL]/trunk/data/lamda/masterlist . (where . would have been
the trunk checkout) instead of svn merge
[URL]/trunk/data/lamda/masterlist data/lamda/masterlist
Another possible case could have been that it was intended to merge the
whole revisions, but by mistake the wrong path was specified.
The fallout was however, that these two "incorrect" mergeinfo entries
ended up in your trunk-mergeinfo and ever since were taken over from there.
I'd certainly correct these on trunk ASAP, if I were you (aka: determine
what was intended and either mark the full trunk as merged, or have the
record correctly on data/lamda/masterlist rather than at trunk).
Taking things from that revision further suggests that in revision 8689
the mergeinfo got correctly added to bracktace/source. This was all fine
until revision 11144. In this revision the trunk-mergeinfo got removed
from backtrace/source for some reason which is beyond what one can
determine by just looking at the revision log.
So all there is to do is to revert the incorrect revert of the mergeinfo
on backtrace/source in r11144 and the following "svn merge ^/trunk ."
should then work just fine.
As stated above: If I were you I'd certainly clean-up the mergeinfo a
bit and at least remove the known cases (aka: materlist-record on trunk
and file-merge hisotry on the zn_19 files).
Regards,
Stefan
Received on 2016-11-08 23:42:04 CET