Todd Denniston wrote:
Julian Opificius wrote:
<SNIP>
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.
julian.
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.
Julian.
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/info-cvs
