On May 27, 2011, at 15:23 , Julian Foad wrote: > > To start simply, I consider a file rather than a directory, on update. > The only relevant tree conflicts are those involving a local file that > exists (because we're talking about copying or moving it), so that's > delete-onto-edited or add-onto-added. Afterwards I'll look at merge, > where more combinations are possible. > > > * File 'foo': tree conflict on update, incoming delete, local edit: > > The default resolution ('mine') is to accept the working version of > 'foo', which has been automatically re-scheduled as copy-from > foo@OLDREV.
On a side note, when you say "working version", are you referring to the ACTUAL tree (including local text edits, prop edits, changelists)? I'm not really up to date on the WC-NG terms. Should we say ACTUAL, implying WORKING, or do we have to say WORKING+ACTUAL? The second form sounds a bit redundant. And should one say "actual tree", without SHOUTING? :-) > But let's say I intend to accept the incoming delete, but I > first want to preserve my edited version under version control under a > different filename, and may want to commit it later. So I either "copy" > or "move" the file to a new name. > > - If I copy the working version of 'foo' to 'bar', I don't expect > 'bar' to be tree-conflicted; it wouldn't make sense because it is a new > object (although copied from foo@OLDREV). The tree conflict must remain > on 'foo', and I can resolve it there. > > - If I move the working version of 'foo' to 'bar', it's a bit > different. Supposing we support "true renames" in the WC, then I would > expect "svn info bar" and "svn resolve bar" to access the tree conflict > on "the node that is currently at working path 'bar' but was at path > 'bar' in the base tree". Some might argue that that is too much of a > conceptual incompatibility with current svn, and might demand that the > user still access 'foo' and 'bar' separately. But if instead I moved > the parent directory that contains 'foo', then I would feel more > strongly that I should be addressing the working path only by its new > name 'parent2/foo'. At the same time, after either one of these moves, > the update editor still needs to see that the base path 'parent/foo' is > a tree conflict victim. So (if we support true renames on the client) > the tree conflict should be logically attached to the versioned node > that is being moved, not just to its base path or its working path. In > implementation terms, the best fit for the current WC DB design would be > to keep the conflict info at the working path, and thus move it whenever > we move the working node. > > - Given that we don't support true renames, I think for now we > should treat "move" the same as "copy plus delete". I agree. Maybe we can make a finer distinction in the future, if the working copy ever includes a "move" operation. > > > * File 'foo': tree conflict on update, incoming add, local add: > > I think this would have the same conclusions as above, but I haven't > gone through this scenario in detail. This seems to be the only kind of tree conflict upon update where BASE isn't shadow-updated. I'm not sure why it isn't. We should investigate. Are there any other situations where BASE is incompletely updated? > > > * File 'foo': tree conflict on merge, incoming delete, local edit; > * File 'foo': tree conflict on merge, incoming add, local add: > > Should a tree conflict on merge behave the same way as on update? > > One difference that doesn't matter but often confuses me is that an > update (or switch) primarily applies the incoming change to the base > tree, and secondarily to the working tree, whereas a merge applies the > incoming change only to the working tree. In a merge, a tree conflict > can only arise on the working tree. In an update the base tree is > always in the expected state, by definition, so again a tree conflict > can only arise on the working tree. > > Because the target of the merge is purely the working tree in the > WC, I feel that if I move the conflict victim or a parent directory of > it, then Subversion should move the conflict (info) with it. But if I > copy it, then it should definitely not copy the conflict. > > ==== > > If all of the above makes sense (a big "if"), the conclusion would be > that a tree conflict on update (or switch) should stay where it was and > not be copied, whereas a tree conflict on merge should stay where it was > unless the copying is part of a move in which case it should be moved. > But that seems a bit inconsistent. I can't quite see yet a simple > consistent model for sensible behaviour. > > And just a thought about one way to partition the implementation: > > * The WC layer never copies tree conflict info when doing a copy > (including a copy that is half of a move). I'm starting with this part of the solution, in the client library. I believe a fix at the WC-layer won't work, because svn_client_move6() ends up calling the following functions: svn_wc_copy3() <--- with metadata_only == TRUE svn_io_file_rename() <--- possibly including conflict-marker files svn_wc_delete4() I think it'll be easier to resolve the conflicts by calling svn_wc_resolved_conflict5() after both copy steps are complete. > > * The client layer "move" and "copy" commands move the conflict info > according to the rules that we decide, e.g. iff it's a tree conflict "on > merge", then it reads and deletes all the tree conflict info from the > source tree and writes it to the destination tree. > >> [...] If I copy the (local, working) file to another name or to >> another directory, the tree conflict (info) should not be copied; just >> the current working version of the file should be copied. >> If I delete the file, strictly speaking the tree conflict (info) >> should remain, although, as a high-level convenience, we might want to >> automatically resolve the conflict at the same time. >> If I move the file, the tree conflict (info) should stay where it was. I'll start by implementing the automatic conflict resolution on copy destinations. Then we can tackle the move-destinations. Steve -- Stephen Butler | Senior Consultant elego Software Solutions GmbH Gustav-Meyer-Allee 25 | 13355 Berlin | Germany tel: +49 30 2345 8696 | mobile: +49 163 25 45 015 fax: +49 30 2345 8695 | http://www.elegosoft.com Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194