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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Johan Corveleyn-4
On Mon, Feb 20, 2017 at 8:50 PM,  <[hidden email]> 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?

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.

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).

--
Johan
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling-9
On Mon, Feb 20, 2017 at 08:57:24PM +0100, Johan Corveleyn wrote:

> On Mon, Feb 20, 2017 at 8:50 PM,  <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

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

Johan Corveleyn-4
On Tue, Feb 21, 2017 at 12:24 PM, Stefan Sperling <[hidden email]> 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.

--
Johan