subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter van Hoof <p.vanh...@oma.be>
Subject Re: merginfo corruption?
Date Mon, 23 Jan 2017 11:10:16 GMT
Hi,

I have been sidetracked by other work for a while, but would like to get 
back to this now...

>> 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).
>
> You're only looking at one path. Mergeinfo is only inherited to paths
> which do not have an svn:mergeinfo property themselves.
>
> In my example above, svn:mergeinfo on the root of the working copy
> is irrelevant for any child (directory or file) within subtree A.
> Only mergeinfo on subtree A is considered for those children (unless
> of course where children have svn:mergeinfo themselves).

The backtrace branch has only been maintained by me, and my routine has 
always been to merge all changes from the root of the trunk to the root 
of the branch and then commit from the root of the branch. So I would 
expect the mergeinfo to be the same on subdirectories or individual 
files. However, when I checked this, I found this not to be the case.

These paths have separate mergeinfo records at r8689:

data/lamda/masterlist/Lamda.ini
source
tsuite/auto/chianti_all_cool.dat
tsuite/auto/chianti_all_cool.in

Apart from "source" they are all files. The full mergeinfo record for 
source is

   svn:mergeinfo
     /branches/HfsLines/source:6561-8024
     /branches/SED/source:6190-7044
     /branches/WangYe/source:5202-5690
     /branches/block/source:6454-6465
     /branches/cden/source:6478-6586
     /branches/chianti/source:5345-5686,6680-6806
     /branches/collapsed/source:7331-8615
     /branches/convergence/source:8443-8533,8561-8633
     /branches/convfix/source:7216-7234
     /branches/depart/source:7256-7655
     /branches/diatoms/source:4635-5051
     /branches/fixct/source:5862-5945
     /branches/gtest/source:7057-7198
     /branches/h2star/source:5156
     /branches/ionrec/source:4983-5281
     /branches/linesInit/source:6627-6633
     /branches/newmole/source:502-6043
     /branches/nstout/source:8422-8435
     /branches/optnl/source:6638-6757
     /branches/ots2/source:6379,6393-6394,6429-6430,6448
     /branches/parser/source:3753,3755,3763
     /branches/parser2/source:7036-7070
     /branches/romas3/source:6262-6786
 
/branches/stout/source:6885-6945,6976-7373,7388-7415,7417-7420,7668-7671,8202-8203,8378-8395
     /branches/stout1/source:8135-8171
     /branches/stout2/source:6109-6538,7581-7619,7694-7706
     /branches/stout3/source:7626-7633,7635-7663
     /branches/sup/source:7503-7533
     /trunk/source:8667-8688

So it has the same information for /trunk as the record at the root. The 
three files with individual mergeinfo records look different. One 
example for tsuite/auto/chianti_all_cool.dat is

   svn:mergeinfo
     /branches/FixWvlng/tsuite/auto/chianti_all_cool.dat:7890-7912
     /branches/collapsed/tsuite/auto/chianti_all_cool.dat:8609-8615
 
/branches/convergence/tsuite/auto/chianti_all_cool.dat:8443-8533,8561-8633
     /branches/nstout/tsuite/auto/chianti_all_cool.dat:8422-8435
     /branches/stout/tsuite/auto/chianti_all_cool.dat:8202-8203,8378-8395

So at revision 8689, the mergeinfo records at the root and the source 
subdirectory both indicate that r8669 is already merged at that point. 
Yet, when I do the merge now (at the head of this branch), it wants to 
merge changes in source/rt_continuum_shield_fcn.cpp from r8669. For me 
this points to corruption in the mergeinfo record or a bug in subversion 
(or both of course...).

So I would like to consider the svn-mergeinfo-normalizer tool that was 
mentioned earlier in this thread. But I need additional guidance on how 
to compile it and how I should use it. Do I need to fix the trunk, or 
the development branch, or both? How does this compare to the 
mergeinfo-sanitizer.py script?


Cheers,

Peter.

Mime
View raw message