GNU bug report logs - #488
VC error: mark-resolved not implemented for CVS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 488 in the body.
You can then email your comments to 488 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: emacs-pretest-bug <at> gnu.org
Subject: VC error: mark-resolved not implemented for CVS
Date: Thu, 26 Jun 2008 17:36:45 -0400

Suppose a CVS file is not up to date.  Set debug-on-error to t.  Make an
incompatible edit to the file, then do

C-x v v

Since the file is not up-to-date, this signals an error, as expected.
So do

C-x v +

to pull in the conflicting changes.  This adds the usual <<< and >>>
lines to the file.  After resolving the changes, try to check in the
file:

C-x v v 

The result:

Debugger entered--Lisp error: (error "Sorry, mark-resolved is not implemented for CVS")
  signal(error ("Sorry, mark-resolved is not implemented for CVS"))
  error("Sorry, %s is not implemented for %s" mark-resolved CVS)
  vc-call-backend(CVS mark-resolved ("/home/cyd/trunk/src/ChangeLog"))
  vc-mark-resolved(CVS ("/home/cyd/trunk/src/ChangeLog"))
  vc-next-action(nil)
  call-interactively(vc-next-action nil nil)

Message #10 received at 488 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: emacs-devel <at> gnu.org
Cc: 488 <at> debbugs.gnu.org
Subject: Re: VC error: mark-resolved not implemented for CVS
Date: Wed, 27 Aug 2008 16:33:39 -0400

> Suppose a CVS file is not up to date.  Set debug-on-error to t.  Make
> an incompatible edit to the file, then do
>
> C-x v v
>
> Since the file is not up-to-date, this signals an error, as expected.
>
> C-x v +
>
> to pull in the conflicting changes.  After resolving the changes,
>
> C-x v v 
>
> Debugger entered--Lisp error: (error "Sorry, mark-resolved is not
> implemented for CVS")

I noticed that doing C-x v + twice causes the file to be marked as
up-to-date.  So maybe C-x v v, when called on a CVS file marked as
conflicted, should try to run `vc-update' again.

Any thoughts?

Message #15 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Dan Nicolaescu <dann <at> ics.uci.edu>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
        488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 15:17:31 -0400

Dan Nicolaescu <dann <at> ics.uci.edu> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>   > > CVS is hardly alone.  In fact, it seems that no other back-end
>   > > implements the mark-resolved action: I tried grepping for
>   > > `mark-resolved' in the vc-*.el files and came up with nothing.
>   > 
>   > There should be a (defalias 'vc-cvs-mark-resolved 'ignore)
>   > Or maybe even (defalias 'vc-default-mark-resolved 'ignore).
>   > But in any case, it seems like the mark-resolved thingy was not
>   > fully implemented if none of the backends define it.
>
> Yep, a pointer to a relevant discussion: 
> http://article.gmane.org/gmane.emacs.devel/94816

I checked in a new function, vc-default-mark-resolved, into vc.el.  It
does nothing except issue a message saying the conflict is resolved.
Someone else can write the vc-*-mark-resolved functions at a later date;
for now, at least `C-x v v' doesn't get stuck at the error.

Message #16 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 16:04:00 -0400

>> > > CVS is hardly alone.  In fact, it seems that no other back-end
>> > > implements the mark-resolved action: I tried grepping for
>> > > `mark-resolved' in the vc-*.el files and came up with nothing.
>> > 
>> > There should be a (defalias 'vc-cvs-mark-resolved 'ignore)
>> > Or maybe even (defalias 'vc-default-mark-resolved 'ignore).
>> > But in any case, it seems like the mark-resolved thingy was not
>> > fully implemented if none of the backends define it.
>> 
>> Yep, a pointer to a relevant discussion: 
>> http://article.gmane.org/gmane.emacs.devel/94816

> I checked in a new function, vc-default-mark-resolved, into vc.el.  It
> does nothing except issue a message saying the conflict is resolved.
> Someone else can write the vc-*-mark-resolved functions at a later date;
> for now, at least `C-x v v' doesn't get stuck at the error.

Thank you.  It shouldn't issue a message, tho: if we want it, we'd want
it in the backend-independent part of the code.


        Stefan

Message #17 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 16:15:43 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> > > CVS is hardly alone.  In fact, it seems that no other back-end
>>> > > implements the mark-resolved action: I tried grepping for
>>> > > `mark-resolved' in the vc-*.el files and came up with nothing.
>>> > 
>>> > There should be a (defalias 'vc-cvs-mark-resolved 'ignore)
>>> > Or maybe even (defalias 'vc-default-mark-resolved 'ignore).
>>> > But in any case, it seems like the mark-resolved thingy was not
>>> > fully implemented if none of the backends define it.
>>> 
>>> Yep, a pointer to a relevant discussion: 
>>> http://article.gmane.org/gmane.emacs.devel/94816
>
>> I checked in a new function, vc-default-mark-resolved, into vc.el.  It
>> does nothing except issue a message saying the conflict is resolved.
>> Someone else can write the vc-*-mark-resolved functions at a later date;
>> for now, at least `C-x v v' doesn't get stuck at the error.
>
> Thank you.  It shouldn't issue a message, tho: if we want it, we'd want
> it in the backend-independent part of the code.

If it doesn't issue a message, then there would be no feedback to the
user that `C-x v v' did anything.  That could be confusing.

Message #18 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 16:23:57 -0400

>>>> > > CVS is hardly alone.  In fact, it seems that no other back-end
>>>> > > implements the mark-resolved action: I tried grepping for
>>>> > > `mark-resolved' in the vc-*.el files and came up with nothing.
>>>> > 
>>>> > There should be a (defalias 'vc-cvs-mark-resolved 'ignore)
>>>> > Or maybe even (defalias 'vc-default-mark-resolved 'ignore).
>>>> > But in any case, it seems like the mark-resolved thingy was not
>>>> > fully implemented if none of the backends define it.
>>>> 
>>>> Yep, a pointer to a relevant discussion: 
>>>> http://article.gmane.org/gmane.emacs.devel/94816
>> 
>>> I checked in a new function, vc-default-mark-resolved, into vc.el.  It
>>> does nothing except issue a message saying the conflict is resolved.
>>> Someone else can write the vc-*-mark-resolved functions at a later date;
>>> for now, at least `C-x v v' doesn't get stuck at the error.
>> 
>> Thank you.  It shouldn't issue a message, tho: if we want it, we'd want
>> it in the backend-independent part of the code.

> If it doesn't issue a message, then there would be no feedback to the
> user that `C-x v v' did anything.  That could be confusing.

Again, if we want feedback, we need it to be in the backend-independent
part of the code, not in the vc-*-mark-resolved method.


        Stefan

Message #19 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 16:27:55 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Again, if we want feedback, we need it to be in the backend-independent
> part of the code, not in the vc-*-mark-resolved method.

So you're saying to introduce ten different functions
(vc-*-mark-resolved) that do the same thing?  That's not pretty.

Message #20 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Dan Nicolaescu <dann <at> ics.uci.edu>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,
        488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 13:43:02 -0700 (PDT)

Chong Yidong <cyd <at> stupidchicken.com> writes:

  > Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
  > 
  > >>> > > CVS is hardly alone.  In fact, it seems that no other back-end
  > >>> > > implements the mark-resolved action: I tried grepping for
  > >>> > > `mark-resolved' in the vc-*.el files and came up with nothing.
  > >>> > 
  > >>> > There should be a (defalias 'vc-cvs-mark-resolved 'ignore)
  > >>> > Or maybe even (defalias 'vc-default-mark-resolved 'ignore).
  > >>> > But in any case, it seems like the mark-resolved thingy was not
  > >>> > fully implemented if none of the backends define it.
  > >>> 
  > >>> Yep, a pointer to a relevant discussion: 
  > >>> http://article.gmane.org/gmane.emacs.devel/94816
  > >
  > >> I checked in a new function, vc-default-mark-resolved, into vc.el.  It
  > >> does nothing except issue a message saying the conflict is resolved.
  > >> Someone else can write the vc-*-mark-resolved functions at a later date;
  > >> for now, at least `C-x v v' doesn't get stuck at the error.
  > >
  > > Thank you.  It shouldn't issue a message, tho: if we want it, we'd want
  > > it in the backend-independent part of the code.
  > 
  > If it doesn't issue a message, then there would be no feedback to the
  > user that `C-x v v' did anything.  That could be confusing.

Does this happen for any other VC backend besides CVS?  

I think (but I can't check at the moment) this only happens because the
backend does not notice the VC state transition, it should not think
that there is a conflict after it has been resolved.
Maybe it's not too hard to test this theory: just make vc-stay-local-p
always return nil and see what happens...

Message #21 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 17:10:47 -0400

>> Again, if we want feedback, we need it to be in the backend-independent
>> part of the code, not in the vc-*-mark-resolved method.

> So you're saying to introduce ten different functions
> (vc-*-mark-resolved) that do the same thing?  That's not pretty.

Not at all.  I have no idea what you're talking about:

backend-independent = code that calls (vc-call mark-resolved ...)

So vc-default-mark-resolved should be an alias for `ignore' and the
message should be in the code that calls (vc-call mark-resolved ...).


        Stefan

Message #22 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 17:18:24 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> Again, if we want feedback, we need it to be in the backend-independent
>>> part of the code, not in the vc-*-mark-resolved method.
>
>> So you're saying to introduce ten different functions
>> (vc-*-mark-resolved) that do the same thing?  That's not pretty.
>
> Not at all.  I have no idea what you're talking about:
>
> backend-independent = code that calls (vc-call mark-resolved ...)
>
> So vc-default-mark-resolved should be an alias for `ignore' and the
> message should be in the code that calls (vc-call mark-resolved ...).

Okay, I misunderstood.

But I still don't see why the message shouldn't be in
vc-default-mark-resolved: if/when a backend actually implements
mark-resolved, it may want to produce a completely different message.

Message #23 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 20:56:54 -0400

> But I still don't see why the message shouldn't be in
> vc-default-mark-resolved: if/when a backend actually implements
> mark-resolved, it may want to produce a completely different message.

Hmm... I see what you mean, but I can't think of reason why that would
ever be the case.  I prefer we keep the code in the generic part
for now.  If we ever come into a case where the message would need to be
different, we'll figure out what to do then.


        Stefan

Message #24 received at 488-done <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dan Nicolaescu <dann <at> ics.uci.edu>, 488-done <at> debbugs.gnu.org
Subject: Re: VC mark-resolved
Date: Wed, 24 Sep 2008 21:47:13 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> But I still don't see why the message shouldn't be in
>> vc-default-mark-resolved: if/when a backend actually implements
>> mark-resolved, it may want to produce a completely different message.
>
> Hmm... I see what you mean, but I can't think of reason why that would
> ever be the case.  I prefer we keep the code in the generic part
> for now.  If we ever come into a case where the message would need to be
> different, we'll figure out what to do then.

Okay, I did that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.