I recently saw some mergeinfo that I can explain but still look wrong to
me. Not sure if it’s a wrong usage of svn, or possibly a defect, and so
far I have not seen any post about this. Here is the scenario (I have a
script, batch file for windows, if needed):
Seen first using svn 1.6.17, confirmed with with svn 1.14.2
Here is the setup:
* Create repo with trunk and branches
* Add a file to trunk
* Create 2 branches from trunk, foo and bar (at this point, neither
branch has mergeinfo for trunk)
* In foo, edit the existing file
* Make some changes in trunk (I added a file)
* Merge trunk to foo (this bring the new file in and adds mergeinfo
for trunk, including the revision where the new file was added)
Now the fun part:
* Do a 2-url merge to merge the changes solely made in foo, and apply
them to bar
The diff between trunk and foo shows only one file was edited (the
second file does not show, since merge made it the same in trunk and
foo). But the diff also shows mergeinfo changed between trunk and foo,
so those get merged to bar, which seem appropriate.
However, it follows that bar now indicates that it has those changes
from trunk (esp. the one revision where the file was added in trunk) but
of course that file is not in bar…And this occurs whether or not I use
–ignore-ancestry.
I could use cherrypicking instead, but I did not want to have to pick
specific changes (I really want all the changes made in foo, but only
those changes)
So,
1)is that a misuse of svn, an unsupported scenario?. Or is there room
for improvement to the mergeinfo management?
2)should I manually delete those “unwanted” mergeinfo? If I don’t, I
have an idea of the issues I can run into. But I am afraid to miss
something here, and removing them would cause other issues.
Thanks
Christophe
