[11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo
cvsnt will try again every second, and either continue with the operation or print the message again, if it still needs to wait. If a lock seems to stick around for an undue amount of time, find the person holding the lock and ask them about the cvs command they are running. If they aren't running a cvs command, and you are not running the lockserver (see the section called “The CVSNT lockserver”, look in the repository directory mentioned in the message and remove files which they own whose names start with #cvs.rfl, #cvs.wfl, or #cvs.lock.
Note that these locks are to protect cvsnt's internal data structures and have no relationship to the word lock in the sense used by rcs--which refers to reserved checkouts (Chapter 11, Multiple developers).
Any number of people can be reading from a given repository at a time; only when someone is writing a file do the locks prevent other people from reading or writing.
If someone commits some changes in one cvs command, then an update by someone else will either get all the changes, or none of them.
By default atomic checkouts occur across an entire checkout, (provided the lockserver is running), but atomic commits are only atomic at the file level. For example, given the files
a/one.c a/two.c b/three.c b/four.c
if someone runs
cvs ci a/two.c b/three.c
and someone else runs cvs update at the same time, the person running update will either get all of the changes, or none of them. If however, the person running cvs commit suffers a power failure in the middle of the commit, it is possible that only one of the files will be updated.