Re: Strange VC/CVS failure

[Jason Rumney]

Andre Spiegel <address@hidden> writes:

> Jason Rumney <address@hidden> writes:
> 
> > A recent change I made to gnus-art.el did not get checked in when I
> > followed the usual VC checkin procedure.
> 
> Hmm, what exact "procedure" is it you are using?  Typing C-x v v,
> entering a log message and typing C-c C-c, which should perform the
> check-in?

C-z C-q, enter log message, C-c C-c. I am then prompted for a
confirmation - this is a new thing that has started happening sometime
in the last two weeks, and may be connected. I am always prompted with
the same question, even on checkins that work.

>  Do you use CVSREAD or some such to make unmodified CVS
> files read-only?

No, my .cvsrc contains only the -z6 flag. I am not using RCS in
parallel.

> I assume this is with a remote repository?

Yes. The Emacs repository.

> What is the state of the file after the check-in has failed?

The file is still there with my changes in it. If I do a `cvs update',
it is reported as `M'(odified).

> The next time it happens, could you have a look at the *vc* buffer and
> see what output was produced by CVS?

Will do. That is what I intended to do on the third attempt (which is why I
did not resort to the command-line), but it worked that time.

> A remote theory that vaguely springs to my mind is that the check-in
> might fail because the repository contains more recent changes and
> these need to be merged into your workfile first.

There were none listed in ChangeLog, but it is possible I guess.

> Could somebody verify that WinCVS (or any other versions of CVS, for
> that matter) indeed use the string "Up-to-date check failed" to
> indicate this condition?

That string does appear in the cvs binary I use. I am not sure how to
force the conditions to test for sure that it is used in those
circumstances.

-- 
Jason Rumney <address@hidden>