[Top][All Lists]

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

Re: problem with lock file when committing file

From: Julian Opificius
Subject: Re: problem with lock file when committing file
Date: Wed, 03 Aug 2005 09:53:20 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Todd Denniston wrote:
Julian Opificius wrote:


Larry got me on track by saying the file itself is being used as the
lock file, which explains the lock directory problem.

However I still have problem that I can't check in a modified file.
Larry suggested that there is a permissions problem on the directory,
but I checked and found that permissions are OK on the project directory
tree - in so far as they're the same as any other directory in the repo.

Is it fundamentally not possible to check in a modified (head) file that
was originally checked out against a tag, even if sticky tags are cleared?

Another question: What is the ".recordref,v" file for ? I have one in
the directory in question on the server.


A possibility from FAR left field, which user owns ,arinc_interface.vhd and
.recordref,v ?
perhaps there was a `kill -9` done on a commit and the offending user needs
to finish the commit?
I would think CVS would clean this up for any user who later did a commit,
but they might have to do it a second time (the first time should do the
clean up).

.recordref,v is 440 to cvs,cvs, along with all other files in the directory. There is no ",arinc_interface.vhd" file. There is an "arinc_interface.vhd" file (without the preceding comma), but its permissions are normal at 440, cvs:cvs.

I can't find anything on ".recordref,v" in the docs, but what worries me is that there is one in several projects, all of which are projects used by one of our hardware people. He's not what you might call a power user of CVS, and I wonder if there's something he's doing that is fargling things up.

With regard to the "kill,9" idea, I don't know what process to look for. Also, I've replicated the project and performed the same actions with the same result, so I don't think there's a dormant thread out there.


reply via email to

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