[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1783790 - /subversion/site/publish/docs/release-notes/1.10.html

From: Johan Corveleyn <jcorvel_at_apache.org>
Date: Tue, 21 Feb 2017 23:36:46 +0100

On Tue, Feb 21, 2017 at 12:24 PM, Stefan Sperling <stsp_at_apache.org> wrote:
> On Mon, Feb 20, 2017 at 08:57:24PM +0100, Johan Corveleyn wrote:
>> Am I right that the same goes for "delete file" (local change) and
>> "edit file" (incoming change)? If so I can extend that row from
>> "delete directory" to "delete item" for the local change.
> Yes.

OK, done in r1783953.

> More generally, the 'mark as resolved' option (aka 'accept current wc state')
> will retain the state left behind after the merge/update/switch operation if
> the state was not modified by the user in the meantime. We could try to make
> the resolver print better descriptions of 'r' options in specific cases, for
> example:
> (r) keep file 'foo' deleted
> Implementing this in a general way would require:
> A) Making a list of all the WC configurations the update/merge/switch
> operations leave behind for many possible tree conflicts to give us
> an idea of where we could improve 'mark resolved' option descriptions.
> B) Implementing checks which verify that the current WC configuration still
> matches this expected configuration, and falling back to the generic
> 'acccept current wc state' description if it does not match.
>> Is it also possible to revert the local deletion and accept the
>> incoming change(s) from within the resolver? I think that would be a
>> nice "alternative action" in this case (but postponing and then
>> reverting from outside of the resolver seems a bit cumbersome and less
>> intuitive for the user).
> There is no option which handles this case yet. It would be good to have one.
> For the moment I have stopped adding more options because I would like to
> implement additional options based on end user feedback, instead of guessing
> what end users might want.

Okay, understood.

Received on 2017-02-21 23:37:09 CET

This is an archived mail posted to the Subversion Dev mailing list.