Hi, I've quickly read through your analysis (I'm interested in seeing tree conflict handling being improved). I'm not sure if I have to interpret the svn commands you give in the different use cases as commands that should currently work (and resolve the tree conflicts). But if so, I've got some remarks, things that might go wrong ... If not, just ignore :).
On Thu, Nov 26, 2009 at 8:01 PM, Daniel Näslund <dan...@longitudo.com> wrote: [...snip...] > cp-add > ------------- > alpha has been locally copied to eta, incoming add eta > Options: > THEIRS:1) svn revert eta > 2) rm eta > 3) svn up eta > MINE: 1) svn resolved eta > RENAME-MINE: 1) svn revert eta > 2) rm eta > 3) svn cp alpha alpha2 > 4) svn up eta I don't think this is correct. My local eta (copy of alpha) might also contain local modifications. Those will be lost in the above resolution. So I would expect: 1) svn mv eta alpha2 2) svn up eta > MERGE: Can't be done at the moment. > > mv-add > ------------- > alpha has been locally moved to eta, incoming add eta > Options: > THEIRS: 1) svn mv eta alpha This will break alpha's line of history, unless this issue is fixed: http://subversion.tigris.org/issues/show_bug.cgi?id=3429 > 2) svn revert eta > 3) svn up eta > MINE: 1) svn resolved eta > RENAME-MINE: 1) svn mv eta alpha > 2) svn mv alpha alpha2 As above, 1) will currently break the line of history. Also, there might be a new alpha (replacing the moved one) in the way, making it impossible to move back to alpha. Why not just "svn mv eta alpha2"? > 3) svn revert eta > 4) svn up eta > MERGE: Can't be done at the moment. > > cp-mv > ----------- > alpha has been locally copied to alpha2, incoming mv alpha to alpha2. > Options: > THEIRS: 1) svn revert alpha2 > 2) rm alpha2 > 3) svn up alpha2 > MINE: 1) svn resolved alpha2 > RENAME-MINE: 1) svn revert alpha2 > 2) svn cp alpha alpha3 Similar to cp-add above, this might lose local modifications on alpha2. Why not just "svn mv alpha2 alpha3"? > 3) rm alpha2 > 4) svn up alpha2 > MERGE: Can't be done at the moment. > > 2. Locale del, incoming del > ========================= > Some use cases: > - Already applied the patch -> want to do it just once -> THEIRS. > - Renamed to two different names -> want to undo Their renaming and > make it like Mine, as if we had a "Choose Mine" option that worked > on whole rename operations. -> RENAME. > > del-mv > -------------- > alpha has been locally deleted, incoming mv alpha to alpha2. > Options: > THEIRS: 1) svn resolved alpha > MINE: 1) svn resolved alpha Is this correct? I suppose "mine" would involve deleting alpha2 ("I told you to delete that object, wherever it is now"). > RENAME: No need > > mv-del > -------------- > alpha has been locally moved to alpha2, incoming rm alpha. > Options: > THEIRS: 1) svn mv alpha2 alpha > 2) svn rm --force alpha (if not used '? alpha' will remain) > 3) svn resolved alpha I'm wondering whether "svn revert alpha2" isn't a better first step? > MINE: 1) svn resolved alpha > RENAME: No need > > mv-mv > ----------- > alpha has been locally moved to alpha3, incoming mv alpha to alpha2. > Options: > THEIRS: 1) svn di -r BASE:PREV > 2) svn rm --force alpha3 > 3) svn resolved alpha > MINE: 1) svn rm --force alpha2 > 2) svn resolved alpha > RENAME: As moves often contain modifications too (like with renamed java classes), shouldn't it be possible to merge those mods, in both the THEIRS and the MINE case? Maybe you should have a THEIRS-FULL and MINE-FULL, ignoring local mods in the other, and THEIRS/MINE should try to merge both contents as well? Or is a move with modifications a different and more complex use case? > > 3. Locale del, incoming edit > ========================== > Some use cases: > - Locally renamed -> want to apply the incoming mod to a different > item -> ELSEWHERE. I would call this MERGE, as you are effectively trying to merge both actions (the move and the edit). > > del-edit > ----------------- > alpha has been locally deleted, incoming edit on alpha. > Options: > THEIRS: 1) svn revert alpha > MINE: 1) svn resolved alpha > ELSEWHERE: Not an option here. > > mv-edit > ------------- > alpha has been locally moved to alpha2, incoming edit on alpha. > Options: > THEIRS: 1) svn mv alpha2 alpha See above: breaks alpha's line of history. > 2) svn revert alpha > MINE: 1) svn resolved alpha > ELSEWHERE: 1) svn merge ^/trunk/alpha alpha2 > 2) svn resolved alpha > > 4. Locale edit, incoming del > ============================= > Some use cases: > - The incoming change is (part of) a rename -> want to transfer my > local mod to the renamed item -> MOVE-MY-MODS. Similar to above, I would call this MERGE. > > edit-del > ---------------- > alpha has been locally modified, incoming delete on alpha. > Options: > THEIRS: 1) svn rm --force alpha > 2) svn resolved alpha > MINE: 1) svn resolved alpha > MOVE-MY-MODS: Not an option here. > > edit-mv > -------------- > alpha has been locally modified, incoming mv alpha to alpha2. > ### If the incoming change had text modifications then we'd have to > ### merge? > Options: > THEIRS: > MINE: 1) svn revert alpha2 > 2) svn resolved alpha > MOVE-MY-MODS: 1) svn revert alpha > 2) rm alpha Are these last scenario's incomplete? Regards, Johan > > /Daniel > > [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3144 > [2] https://www.inf.fu-berlin.de/w/SE/ThesisTreeConflicts >
