cvs join update

[Murugaiyan, Natarajan [IT]]

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.

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.

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)