On Mon, Feb 20, 2017 at 08:57:24PM +0100, Johan Corveleyn wrote:
> On Mon, Feb 20, 2017 at 8:50 PM, <jcor...@apache.org> wrote:
> > Author: jcorvel
> > Date: Mon Feb 20 19:50:38 2017
> > New Revision: 1783790
> >
> > URL: http://svn.apache.org/viewvc?rev=1783790&view=rev
> > Log:
> > * publish/docs/release-notes/1.10.html: put "keep working copy state" as
> > resolution option for local change "deleted directory".
> >
> > Modified:
> > subversion/site/publish/docs/release-notes/1.10.html
> >
> > Modified: subversion/site/publish/docs/release-notes/1.10.html
> > URL:
> > http://svn.apache.org/viewvc/subversion/site/publish/docs/release-notes/1.10.html?rev=1783790&r1=1783789&r2=1783790&view=diff
> > ==============================================================================
> > --- subversion/site/publish/docs/release-notes/1.10.html (original)
> > +++ subversion/site/publish/docs/release-notes/1.10.html Mon Feb 20
> > 19:50:38 2017
> > @@ -350,9 +350,10 @@ href="https://wiki.apache.org/subversion
> > <td><ul>
> > <li>any change inside directory</li>
> > </ul></td>
> > - <td>update, switch</td>
> > + <td>update, switch, merge</td>
> > <td><ul>
> > - <li>...</li>
> > + <li>keep working copy state (deleted directory),<br>
> > + discarding incoming changes</li>
> > </ul></td>
> > </tr>
> > </table>
>
> Stefan, I suppose the above is correct (for update, switch and merge),
> and corresponds to the (r) (mark as resolved) option, right?
Yes.
> 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.
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.
