On Tue, Feb 7, 2017 at 1:11 PM, Stefan Sperling <s...@elego.de> wrote: > On Tue, Feb 07, 2017 at 12:40:10PM +0100, Johan Corveleyn wrote: >> BTW: why no "deleted an item" for local change (can't look at the code >> / resolver options right now myself, so just wondering ...)? > > I've just added one case where the resolver has special-purpose code for > that (code which already existed in 1.9): https://svn.apache.org/r1781991 > This case is in the first row (incoming edit vs local delete/move), > and updates children which were moved out of the directory before the > directory itself was deleted. > > Apart from 'accept current working copy state' (aka postpone), there > is no other case where the resolver code looks for a local change > with reason code svn_wc_conflict_reason_deleted. > It is quite possible that the resolver is missing a lot of other cases > where this condition would apply!
Okay, I did some table-reshuffling attempt in r1782093. Feel free to change it further or to revert back if you think it's worse than before. I attempted to eliminate the 'operation' column as well, because there is overlap between the resolution options of 'update, switch' and 'merge'. But then I ended up "annotating" somehow the resolution options that were specific to an operation, which got a bit confusing (especially because some resolution options already use the term 'merge' in another meaning as the 'merge' operation). So for now I thought it best to leave the 'operation' column in there (unless the options start looking more and more the same). Concerning 'delete a directory', I don't fully understand what you meant, so I left that resolution option with '...'. What I'd expect to be possible, if I had locally deleted a directory or a file, is to ignore any incoming change, and just accept the working copy situation (i.e. deleted) -- not postponing, but just accepting the working copy situation and mark it as resolved. The other interesting option would probably be: revert my local deletion and apply the incoming change. -- Johan