RE: Info-cvs digest, Vol 1 #221 - 11 msgs

[Graeme . Vetterlein]

> cvs isn't reading the incoming socket.  inetd is reading the
> incoming information and passing it on to the stdin of the 
> cvs process.
> So in this case only one process is actually reading all incoming
> sockets.

Slightly at a tangent for this group but this is not how inetd
works. It accepts(2) the incomming request then fork(2)s off the child
(cvs) who really reads the data, so the reader IS csv.

However, as the man says ...

> You're confusing ports with sockets.  ...



However I'm very interested in this comment:

lj> remember directory contention via lock files could also be 
lj> significantly
lj> slowing down updates as well.  Especially over such a large 
lj> repository.
lj> 
lj> If everyone is doing update, they're read locks which are sharable, so
lj> there shouldn't be any significant contention.
lj> 
lj> -Larry Jones

I've notice I ALWAYS get this "waiting for lock" type message.
I've always had just a single file being commited at a time.

updatelog> Monday January  8 10:21:21 GMT 2001
updatelog> Update of /users/cvsroot/com/ntl/toys/htmlutil
updatelog> In directory sunprototype1:/tmp/cvs-serv4184
updatelog> 
updatelog> Added Files:
updatelog>      Grab.java 
updatelog> Log Message:
updatelog> First Version
updatelog> $1=com/ntl
updatelog> $2=com/ntl/toys/htmlutil
updatelog> $3=Grab.java
updatelog> $4=NONE
updatelog> $5=1.1
updatelog> About to do cvs cmd
updatelog> cvs checkout: Updating com/ntl/toys/htmlutil
updatelog> cvs checkout: [10:21:23] waiting for priorc's lock in
/users/cvsroot/com/ntl/toys/htmlutil
updatelog> Done cvs cmd
updatelog> About to do lastman cmd
updatelog> Done lastman cmd
updatelog> cvs checkout: [10:21:53] obtained lock in
/users/cvsroot/com/ntl/toys/htmlutil
updatelog> U com/ntl/toys/htmlutil/Grab.java

This is caused by:

loginfo> ^utils $CVSROOT/bin/tedcheckin utils %{s V v}

Which calls:

... sorry this so long .. but I don't want to skip the comments.

tedcheckin> exec >> $CVSROOT/CVSROOT/updatelog 2>&1
tedcheckin> 
tedcheckin> PATH=$PATH:/usr/local/bin:${CVSROOT}/bin export PATH
tedcheckin> 
tedcheckin> SOURCE=/users/projects/src
tedcheckin> 
tedcheckin> 
tedcheckin> date
tedcheckin> cat
tedcheckin> 
tedcheckin> module=$1
tedcheckin> 
tedcheckin> OLDFS=${IFS}
tedcheckin> 
tedcheckin> IFS=" ," 
tedcheckin> set -- $*
tedcheckin> 
tedcheckin> #
tedcheckin> # OK here:
tedcheckin> #
tedcheckin> # $1 = Module (fixed set see CVSROOT/loginfo)
tedcheckin> # $2 = Directory where the file is being checked in relative to
$CVSROOT
tedcheckin> # $3 = File being checked in
tedcheckin> # $4 = old version number
tedcheckin> # $5 = new version number
tedcheckin> #
tedcheckin> 
tedcheckin> sleep 2
tedcheckin> cd ${SOURCE}
tedcheckin> 
tedcheckin> echo '$1'"=$1"
tedcheckin> echo '$2'"=$2"
tedcheckin> echo '$3'"=$3"
tedcheckin> echo '$4'"=$4"
tedcheckin> echo '$5'"=$5"
tedcheckin> 
tedcheckin> module=$1
tedcheckin> dir=$2
tedcheckin> file=$3
tedcheckin> o_ver=$4
tedcheckin> n_ver=$5
tedcheckin> 
tedcheckin> echo "About to do cvs cmd"
tedcheckin> cvs checkout ${dir} &
tedcheckin> echo "Done cvs cmd"
tedcheckin> 
tedcheckin> #
tedcheckin> # Now we want to force the rebuild of this stuff
tedcheckin> # however we don't want to do one rebuild everytime a single
file goes in
tedcheckin> # instead we want do a 'piece of work' . To acheive this we wait
'a little while'
tedcheckin> # to see if the checkin storm has ended then do a dobuild
tedcheckin> #
tedcheckin> 
tedcheckin> #
tedcheckin> # Assemble a list of what's been checked in
tedcheckin> #
tedcheckin> echo "${module} ${dir} ${file} ${o_ver} ${n_ver}"  >>
${SOURCE}/${module}/.nextbuild
tedcheckin> 
tedcheckin> #
tedcheckin> # Last man in builds the lot
tedcheckin> #
tedcheckin> echo "About to do lastman cmd"
tedcheckin> lastman ${SOURCE}/${module}/.touch 30 "dobuild ${module}" &
tedcheckin> echo "Done lastman cmd"
tedcheckin> 
tedcheckin> exit 0

Note the sleep as in: http://www.cvshome.org/docs/manual/cvs_18.html#SEC171

...oh dear as I type this I'm wondering if I've got that & in the right
place. Was the
intent of this 'magic rune' to allow the one process to sleep while the
original did something? 
(with locks)

--
Graeme