subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Corveleyn <>
Subject Re: svn commit: r1780191 - /subversion/site/publish/docs/release-notes/1.10.html
Date Wed, 08 Feb 2017 00:59:24 GMT
On Tue, Feb 7, 2017 at 1:11 PM, Stefan Sperling <> 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):
> 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

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.


View raw message