Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Krzysztof and Colin,
Can you please provide more information about this - we cannot reproduce
this error.
> We are making builds from different branches. Each build has its unique
> name and this name is used to RTAG source files in CVS.
> As these are different branches, two (or more) RTAG operations are
> performed in parallel from different build machines.
> In case there is only one build machine, we could run builds sequentially,
> but having more than one build machines, it is more efficient
> to run builds in parallel.
Tony has ran some tests and when he deliberately creates a situation where
two processes try and tag the same file at the same time what results is
this (in this case the second process):
D:\t\CVSROOT>cvs tag c
cvs tag: Tagging .
cvs tag: [14:26:30] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:31] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:32] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:33] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:34] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:35] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:36] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:37] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:38] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:39] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:40] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:41] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:42] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:43] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:44] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:45] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:46] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:47] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:48] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs tag: [14:26:49] waiting for tmh's lock in /repo/CVSROOT/checkoutlist,v
cvs [tag aborted]: Failed to obtain lock on checkoutlist,v
This is what we would identify as the correct intended behaviour - though
producing this in the 'real world' should be very difficult. If you run two
rtag operations from two different build machines and you regularly get this
problem the easiest way to work around it is start one build one minute
later, however I also recommend looking closely at why the processes on the
server are running in such a synchronised state - each tag should only be
taking a few milliseconds and differences in disk access and the network
communication with the client should be random enough to ensure these
conflicts do not occur.
The only case that I can think of where you could possibly lose data as
described is if the two rtags are running on two machines but using :local:
protocol with a samba sharem, an nfs share or a multi-port SAN, eg:
cvs -d /usr/local/repo rtag -rbranch1 release_1_1_1
or
cvs -d :local:/usr/local/repo rtag -rbranch1 release_1_1_1
The local protocol is only for our internal developer use, and cannot
co-ordinate locking over several hosts.
Can you provide more information about this rtag 'bug'? Do any of the
examples I have described explain what you have experienced? Can you
provide the build scripts you are using? Can you provide the the
trace/log/cronlog of the build when the error occurred?
Regards,
Arthur Barrett