On 12/12/06, Andy Random <andy.random@???> wrote:
> I'm looking for a way to lock a CVS repository during backup.
>
> I've only just started working with CVS and I've inherited a backup method
> which takes the CVS server offline, backs up and then restart it.
>
> However there is now a requirement to run some automated processes
> overnight which need read access to the CVS server and the backup is
> getting in the way. So I'm looking for a way to lock all the repositories
> so no changes can be made but read access is still available, do the
> backup and then unlock everything again.
If you're exclusively using pserver access, create an empty
CVSROOT/writers file:
http://www.mail-archive.com/info-cvs@gnu.org/msg33409.html
This will not stop people authenticating using ssh or run cvs commands
locally on the cvs server. Other options listed in that thread include
making the CVSROOT/commitinfo script fail during the backup. You'd
also need to make sure that there are no cvs operations ongoing when
you start the backup.
> I'd have thought this was a fairly standard sort of requirement but as I
> said I'm new to CVS.
>
> I've found information on using #cvs.rfl/#cvs.wfl/#cvs.lock to lock a
> directory, but as I understand it this requires you to lock each directory
> individually and there are literally thousands of directories which need
> locking.
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.
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.
G
