Murugaiyan, Natarajan [IT] wrote:
Why does cvs join update command cvs -d /opt/fdtssrc/gfdtssrc1 update -j HEAD try to acquire a lock in the repository?
I am using CVS 1.11.6 in Solaris 8 and above command fails with this error message: cvs update: failed to create lock directory for `/opt/fdtssrc/gfdtssrc1/tkbatch' (/opt/fdtssrc/gfdtssrc1/tkbatch/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository `/opt/fdtssrc/gfdtssrc1/tkbatch' cvs [update aborted]: read lock failed - giving up
The join command updates the working copy and not the repository. Don't know why this operation
needs a lock on repository directory.
#cvs.lock acts as a master lock used to synchronize other lock obtaining operations.
Like any well behaved lock management system, CVS obtains read locks (#cvs.rfl)
for read operations like update/checkout etc. Readers don't conflict with other
readers, but they do conflict with writers. A writer will be blocked till the read
lock is relinquished by a reader. This is your basic read-write locking protocol at
work.
Locks are created per directory. If the CVS process can not create the dir (#cvs.lock)
due to group permission issues, it will balk. Make sure the user belongs to a group
that can write.
The -n option will not attempt to get any locks will not therefore try to create the dir (#cvs.lock)
I guess making /opt/fdtssrc/gfdtssrc1/tkbatch directory to be group writable and adding user executing the join command to be in that group would fix this problem.
Yup that is needed.
The source repository directories are not group writable and accessed through pserver.
The noexec join command 'cvs update -n -j HEAD' does not work through pserver and fails with this error:
$ cvs -n update -j HEAD cvs server: Updating .
cvs server: Updating CVSADMIN
RCS file: /opt/fdtssrc/gfdtssrc1/tkbatch/CVSADMIN/release,v
retrieving revision 1.8
retrieving revision 1.10
Merging differences between 1.8 and 1.10 into release
cvs server: release: No such file or directory
The same command works when pserver is bypassed with -d argument $ cvs -d /opt/fdtssrc/gfdtssrc1 -n update -j HEAD
With the non-group writable repository directory setup, the cvs join(without noexec option) fails when bypassing pserver(because of unable to get read lock) but works when using pserver.
Not sure opening up repository directories to be group writable so that users can run cvs update join {with/without} -n option successfully by bypassing the pserver.
Any ideas?
Natarajan Murugaiyan(Ravi)
_______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
_______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
