Below is the output of running cvs commit on my local repos. As you can
see the update tries to run on the server side but when it gets to the
directory where I edited a file it has a lock error. I'm guessing it's
locked for the commit there for the update won't run on it.
Checking in header.tpl;
/home/james/cvsroot/webapp/smarty/templates/header.tpl,v <-- header.tpl
new revision: 1.4; previous revision: 1.3
done
cvs update: Updating .
cvs update: Updating htdocs
cvs update: Updating htdocs/css
cvs update: Updating htdocs/images
cvs update: Updating includes
cvs update: Updating smarty
cvs update: Updating smarty/cache
cvs update: Updating smarty/configs
cvs update: Updating smarty/templates
cvs update: [00:09:51] waiting for james's lock in
/home/james/cvsroot/webapp/smarty/templates
On Sun, 17 Dec 2006, Ingo Schwarze wrote:
James Turner wrote on Sat, Dec 16, 2006 at 11:28:43PM -0500:
jcs@ suggested looking at loginfo in CVSROOT, but I haven't had much luck
there. I added "^webapp cd /var/www/webapp && cvs update -d" but there
seems to be a locking issue, I'm guessing cvs update tries to run before
the commit is finished, which it won't allow.
Are you sure? `info cvs` says on page "C.3 The commit support files":
:: `loginfo'
:: The specified program is called when the commit is complete.
/usr/bin/cvs is neither suid nor sgid. Did the user typing `cvs commit`
have write permission below /var/www/webapp?
If write permission below /var/www/webapp is indeed the issue
biting you, the simple solution is putting /var/www/webapp into
the same group the repository belongs to - the committing users
need write access to the repository anyway, so additional write
access to the web tree will cause little additional harm.
