info-cvs
[Top][All Lists]
Advanced

[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 08:39:10 -0500
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Todd Denniston wrote:
Julian Opificius wrote:

Todd Denniston wrote:

Julian Opificius wrote:

<SNIP>

No, my primary heartache is the intended location of the lock file in
the message, which is not where my configuration keeps lock files - I
use /var/lock for that so I can use pserver to prevent unlogged write
access to the repository.


<SNIP>

Q2) did you edit $CVSROOT/CVSROOT/config {to mod the LockDir variable} in
$CVSROOT/CVSROOT/

 or did you do a `cvs -d $CVSROOT checkout CVSROOT` and

edit it in the checked out location then do a checkin? Note that except for
the password file, the second method (`cvs checkout CVSROOT`) is the way all
the files in $CVSROOT/CVSROOT should be edited.

Yes, I did the latter.


Q3) did you do a checkin in $CHECKOUTPATH/CVSROOT?

I don't understand this question.


I wanted to make sure you checked in any edits you made to the config files.
i.e., does less /usr/local/cvsroot/CVSROOT/config
show the file containing what you expect?


Bear in mind we're using WinCVS client on Windows, we're not using Xnix
clients.


Should not matter from a CVS perspective (even for the problem you are
having), though the non-CVS commands I suggest you issue are generally
expected to be done on the Unix host you are using as a server. ... Let me
make sure the assumption I have from the paths you use is correct: You are
using CVS|CVSNT on a Unix host as your server, not CVS|CVSNT on a cygwin
host?

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.






reply via email to

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