On Mon, Nov 30, 2009 at 12:25:15PM +0100, Johan Corveleyn wrote: > 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 :).
Thanks for your comments. The commands were indeed an attempt to resolv the tree conflicts with the svn commands available today. This is a first 'scratch on the surface'. I have a limited experience of handling tree conflicts and thought that some real use cases would give me some more in-depth knowledge before I dive into writing a spec. > On Thu, Nov 26, 2009 at 8:01 PM, Daniel Näslund <dan...@longitudo.com> wrote: > > 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 Correct. As goes for many of the other scenarios I hadn't thought much about local text changes. > > 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 I wasn't aware of #3429 - move back and forth generates replace. Will keep that in mind as I proceed. > > 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"? Good point. The resolver will have to prompt the user for a new path. [...] > > 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"). Yeah, my mistake. > > 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? This is one of the (many) parts I haven't figured out yet. How handle conflicts with more than one "component" such as a move with modifications. > > 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 > > 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? Yes, I need to do some thinking about how to handle files with modifications. >From my point of view, it should be doable to write conflict resolvers for tree conflicts on files during update for most of the presented use cases. The merging of modifications on tree conflicts is an area where I'll have to do more thinking. Again, thanks for the feedback Daniel
