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_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).
>
> 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.
Received on 2017-01-23 12:10:29 CET