Could you post the script, please? It's hard to answer your question when it describes the details verbally rather than machine-readably.
It sounds like a supported scenario. Cheers, Daniel Christophe Royer wrote on Fri, 06 May 2022 21:46 +00:00: > 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
