Thanks for the replies.
On Tue, 12 Dec 2006, Graham Bleach wrote:
> At least some read-only operations wait on locks. When running a cvs
> export of the same repo path concurrently on multiple nodes, several
> nodes will wait on locks in the repository.
They do? That seems crazy to me, but I guess I shouldn't be surprised, the
more I learn about CVS the more I dislike it... however I guess that blows
the idea of using CVS locks out the water.
> An alternative view is not to worry too much, especially if you keep
> incremental backups. You might have a few corrupt rcs files caused by
> in-progress commits, but as long as the next night's incremental
> catches them, you should be able to salvage something. It's much less
> serious in a source control system with no concept of internal
> consistency.
Yes I read something similar to this in the documentation, unfortunately
this isn't an option here at least in part for political reasons.
On Tue, 12 Dec 2006, Steve Kemp wrote:
> This is the option I've chosen in the past, creating a commitinfo
> script which looked for /home/cvs/LOCKED - if present it would fail.
>
> That mean we could enable/disable the commits just by
> touching/deleting single file, something that the backup server managed
> itself.
That sounds like it might be a possibility, though are commits the only
write operation I need to worry about, what about things like applying
tags and creating branches?
Just to test my understanding of the way CVS works, am I right in thinking
that adding a line something like:
ALL /usr/local/bin/check_lock.pl
to commitinfo and then having the check_lock.pl script look for the the
lock file and return a non zero value if it exists will implement what you
outline above and prevent commits from happening?
Also it looks like commitinfo exists per repository, so I assume to
implement this for the whole server I'd need to add it to each repo and
ensure that it was put in place in any newly created repositories as well?
Andy
