On Wed, Feb 08, 2017 at 01:59:24AM +0100, Johan Corveleyn wrote:
> On Tue, Feb 7, 2017 at 1:11 PM, Stefan Sperling <stsp_at_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.
Thanks! Looks good to me :)
> 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.
I mixed something up: 'accept current working copy state' maps to 'mark
resolved', not 'postpone'. So you could use the 'accept current working
copy state' option in this case and it should do what you expect.
Received on 2017-02-08 11:20:23 CET