bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"cvs commit: Up-to-date check failed for `file'" is wrong error.


From: Todd Denniston
Subject: "cvs commit: Up-to-date check failed for `file'" is wrong error.
Date: Thu, 14 Jul 2005 12:15:21 -0500

Hi folks,
I have a developer who just went from client 1.11.17 to client 1.11.19
(transition from FC 2/3 to FC 4, both as delivered by yum from Fedora) and
ran into an error he had not seen in his normal work before. Also the
command he used is the way he has done it for a long time which is why I
believe it to be related to the upgrade.

The server is cvs 1.11.17, over :pserver:.

The error was 
cvs commit: Up-to-date check failed for `file'

cvs update was done several times without making the situation better, and
there were no conflict markers.  After I worked on the problem for several
minutes I noticed that the commit command he was using looked like
`cvs commit ../dir1 ../dir2/subdir1/subdir2 file`
and remembered some change to cvs several releases ago that got so it did
not trust '..' in commands. I 'cd ..' and reconfigured his command with
respect to that
`cvs commit dir1 dir2/subdir1/subdir2 dir3/file`, and it worked.

It seems to me that the error should have been something along the lines
"'..' not allowed.", looking in cvs-1.11.20 there is a message in client.c
that seems related 
"backreference in path (`..') not supported by old (pre-Max-dotdot) servers"
or in server.c
"protocol error: `%s' contains more leading .." or 
"E protocol error: `%s' has too many .."


Fedora lists the cvs rpm as "cvs-1.11.19-8" so they may have done some
Fedora specific mods or just patched in the security fixes from a later
version.

I have attempted to recreate the error on a different box (FC2) using
cvshome.org cvs-1.11.20 with direct, :fork: and :pserver: with out success,
I have asked the user to involve me in the next commit so I can verify it is
happening reliably with his box, and will attempt my tests again with that
FC4 version. If I can recreate it, I wanted to figure out which of the
conditions:
        case T_CHECKOUT:
        case T_PATCH:
        case T_NEEDS_MERGE:
        case T_CONFLICT:
        case T_REMOVE_ENTRY:
in commit.c:check_fileproc was causing the Up-to-date check fail, but I have
run out of time for today and wanted to see if someone else had some
more/different insite.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]