bug#3860: vc-svn calls "svn resolved" without permission

bug#3860: vc-svn calls "svn resolved" without permission

[James Y Knight]

Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on  
Debian Lenny), and was a bit disappointed to discover that vc-svn is  
now automatically calling "svn resolved" on files when I save them  
after removing conflict markers.

I use svn's list of conflicted files while working on merges, and tend  
to only call "resolved" on them when I'm *actually done* fixing a  
group of files. I'll note that emacs automatically calling "svn  
resolved" also destroys the .mine, .rOLD, and .rNEW files, which I  
wasn't actually done with yet. Having them disappear out from under me  
just because I've *partly* fixed things and saved is very  
counterintuitive!

There's a reason that svn makes you run "svn resolved" on files to  
note them as resolved instead of just checking for the lack of  
conflict markers, and vc-svn is totally destroying that nice behavior  
of svn. If it was a good idea to autoresolve when there's no conflict  
marker in the file, then "svn commit" would already do that!

IMO, the function "vc-svn-resolve-when-done" should just be removed  
entirely. But if not, it really should *at least* be asking for  
confirmation first before causing the merge working data to be deleted.

Relatedly, it would also be great if there was a key to run svn  
resolved. I've had this addition in my .emacs for a while to achieve  
that:

(defun svn-resolved ()
   "Resolve conflict on current buffer"
   (interactive)
   (shell-command (concat "svn resolved " (buffer-file-name))))
(define-key 'vc-prefix-map "R" 'svn-resolved)

James

bug#3860: vc-svn calls "svn resolved" without permission

[Lars Ingebrigtsen]

James Y Knight <jknight@fuhm.net> writes:

> Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on
> Debian Lenny), and was a bit disappointed to discover that vc-svn is
> now automatically calling "svn resolved" on files when I save them
> after removing conflict markers.

(I'm going through old bug reports that unfortunately got no response at
the time.)

This behaviour still seems to be present in Emacs 28, as far as I can
see.

> I use svn's list of conflicted files while working on merges, and tend
> to only call "resolved" on them when I'm *actually done* fixing a
> group of files. I'll note that emacs automatically calling "svn
> resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
> wasn't actually done with yet. Having them disappear out from under me
> just because I've *partly* fixed things and saved is very
> counterintuitive!

I haven't used SVN myself in ages, and I don't even recall what my work
flow used to be.  However, adding a variable to suppress
`vc-svn-resolve-when-done' might make sense?  Anybody who actually uses
SVN still got an opinion here?

That this bug report is 11 years old and there doesn't seem to be any
other bug reports about this does perhaps indicate that people are fine
with how it works, and nothing should be done here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3860: vc-svn calls "svn resolved" without permission

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 21 Jan 2021 17:41:08 +0100
> Cc: 3860@debbugs.gnu.org, spiegel@gnu.org
> 
> > I use svn's list of conflicted files while working on merges, and tend
> > to only call "resolved" on them when I'm *actually done* fixing a
> > group of files. I'll note that emacs automatically calling "svn
> > resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
> > wasn't actually done with yet. Having them disappear out from under me
> > just because I've *partly* fixed things and saved is very
> > counterintuitive!
> 
> I haven't used SVN myself in ages, and I don't even recall what my work
> flow used to be.  However, adding a variable to suppress
> `vc-svn-resolve-when-done' might make sense?  Anybody who actually uses
> SVN still got an opinion here?

I think if we are going to make this optional with SVN, we should make
it optional with the other back-ends as well.  VC always presented a
uniform UI and user experience with all back-ends, as far as possible
and reasonable.  In this case, I think automatically marking the
conflicts as resolved makes a lot of sense, but I won't object to make
it opt-out, as long as it's done for every VCS that can support it.

bug#3860: vc-svn calls "svn resolved" without permission

[Dmitry Gutov]

On 21.01.2021 21:33, Eli Zaretskii wrote:
> I think if we are going to make this optional with SVN, we should make
> it optional with the other back-ends as well.  VC always presented a
> uniform UI and user experience with all back-ends, as far as possible
> and reasonable.  In this case, I think automatically marking the
> conflicts as resolved makes a lot of sense, but I won't object to make
> it opt-out, as long as it's done for every VCS that can support it.

So someone might want to generalize the Git-specific variable: 
vc-git-resolve-conflicts.

But they'd have to consider what to do with the special value 
'unstage-maybe', which doesn't really make sense for other backends.

bug#3860: vc-svn calls "svn resolved" without permission

[Eli Zaretskii]

> Cc: 3860@debbugs.gnu.org, jknight@fuhm.net, spiegel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 22 Jan 2021 00:35:07 +0200
> 
> On 21.01.2021 21:33, Eli Zaretskii wrote:
> > I think if we are going to make this optional with SVN, we should make
> > it optional with the other back-ends as well.  VC always presented a
> > uniform UI and user experience with all back-ends, as far as possible
> > and reasonable.  In this case, I think automatically marking the
> > conflicts as resolved makes a lot of sense, but I won't object to make
> > it opt-out, as long as it's done for every VCS that can support it.
> 
> So someone might want to generalize the Git-specific variable: 
> vc-git-resolve-conflicts.

Yes, I think so.

> But they'd have to consider what to do with the special value 
> 'unstage-maybe', which doesn't really make sense for other backends.

Right.

bug#3860: vc-svn calls "svn resolved" without permission

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> So someone might want to generalize the Git-specific variable:
> vc-git-resolve-conflicts.

Yeah, makes sense.

> But they'd have to consider what to do with the special value
> 'unstage-maybe', which doesn't really make sense for other backends.

Yup.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#3860: vc-svn calls "svn resolved" without permission

[James Y Knight]

On Thu, January 21, 2021 11:41 am, Lars Ingebrigtsen wrote:
> James Y Knight <jknight@fuhm.net> writes:
>
>> Hi, I recently just switched to from Emacs 21 to Emacs 22 (22.2.1, on
>> Debian Lenny), and was a bit disappointed to discover that vc-svn is
>> now automatically calling "svn resolved" on files when I save them
>> after removing conflict markers.
>
> (I'm going through old bug reports that unfortunately got no response at
> the time.)
>
> This behaviour still seems to be present in Emacs 28, as far as I can
> see.
>
>> I use svn's list of conflicted files while working on merges, and tend
>> to only call "resolved" on them when I'm *actually done* fixing a
>> group of files. I'll note that emacs automatically calling "svn
>> resolved" also destroys the .mine, .rOLD, and .rNEW files, which I
>> wasn't actually done with yet. Having them disappear out from under me
>> just because I've *partly* fixed things and saved is very
>> counterintuitive!
>
> I haven't used SVN myself in ages, and I don't even recall what my work
> flow used to be.  However, adding a variable to suppress
> `vc-svn-resolve-when-done' might make sense?  Anybody who actually uses
> SVN still got an opinion here?
>
> That this bug report is 11 years old and there doesn't seem to be any
> other bug reports about this does perhaps indicate that people are fine
> with how it works, and nothing should be done here.

I haven't used svn in years at this point, so I really don't care what
happens with vc-svn anymore. But I had personally long ago worked around
this bug with:
(defadvice vc-svn-resolve-when-done (around dont-svn-resolve activate)
  nil)

However, I will mention that I find the equivalent behavior in Emacs's Git
integration just as bad -- for the same reason of it discarding important
information! There's a reason that "git add" is a separate operation, and
having emacs silently run that when doing a "save" operation destroys
information, unexpectedly.

I really think this behavior should _never_ have been made default
behavior in _any_ VC mode. Discarding data is quite a bad default, and
extremely unexpected from "save". But, hey, at least vc-git can be
configured, so that's nice.

(And, I'll note that it took me at least a _year_ to figure out that the
broken behavior after resolving conflicts in Git was an emacs vc-git bug,
and not Git itself having lost the ability to 3-way-conflict-diff the
conflict resolution! It's incredibly non-obvious that emacs is breaking
this!)

I'm not the only one to complain about this, e.g.
https://emacs.stackexchange.com/questions/51206/disabling-automatic-add-after-resolving-git-conflict

For that matter, bug 20292 which added the emacs config option has
multiple complaints about this behavior, as well...

bug#3860: vc-svn calls "svn resolved" without permission

[Dmitry Gutov]

On 25.01.2021 00:36, James Y Knight wrote:

> I haven't used svn in years at this point, so I really don't care what
> happens with vc-svn anymore. But I had personally long ago worked around
> this bug with:
> (defadvice vc-svn-resolve-when-done (around dont-svn-resolve activate)
>    nil)

Fair enough.

> However, I will mention that I find the equivalent behavior in Emacs's Git
> integration just as bad -- for the same reason of it discarding important
> information! There's a reason that "git add" is a separate operation, and
> having emacs silently run that when doing a "save" operation destroys
> information, unexpectedly.
> 
> I really think this behavior should _never_ have been made default
> behavior in _any_ VC mode. Discarding data is quite a bad default, and
> extremely unexpected from "save". But, hey, at least vc-git can be
> configured, so that's nice.
> 
> (And, I'll note that it took me at least a _year_ to figure out that the
> broken behavior after resolving conflicts in Git was an emacs vc-git bug,
> and not Git itself having lost the ability to 3-way-conflict-diff the
> conflict resolution! It's incredibly non-obvious that emacs is breaking
> this!)
> 
> I'm not the only one to complain about this, e.g.
> https://emacs.stackexchange.com/questions/51206/disabling-automatic-add-after-resolving-git-conflict
> 
> For that matter, bug 20292 which added the emacs config option has
> multiple complaints about this behavior, as well...

"Multiple complaints" seems to be an overstatement: we have one question 
of SE, and one disagreement in the bug comments. The disagreement is 
from the current Git maintainer, which is significant, but still not a 
gospel, since VC tries to provide a "unified" interface to many VCSes, 
not just Git.

That said, I personally customize vc-git-resolve-conflicts to nil, and 
'C-x v v' now does resolve the conflicts all right (even though it 
doesn't refresh the vc-state of such buffers automatically). So nil 
works okay, and it would be my vote.

But the current behavior of that variable and its default value have 
been requested by Emacs maintainers, one former and one current. As 
such, I'll let the maintainers decide on whether the default can be 
changed here.

bug#3860: vc-svn calls "svn resolved" without permission

[Lars Ingebrigtsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But the current behavior of that variable and its default value have
> been requested by Emacs maintainers, one former and one current. As
> such, I'll let the maintainers decide on whether the default can be
> changed here.

I have found the way Emacs handles conflicts somewhat confusing a few
times, but I'm not sure whether this is due to the automatic resolving
or not.  I'll try to pay more attention next time.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no