Re: CVS lock script

[Matthew Ogilvie]

To update a repository file (commit, tag, etc), CVS writes a temporary
file, and then "atomically" rename()'s it on top of the original file.

So the backup might pick up junk/temporary files and/or stale
locks, and there might be conditions where the rename() interacts
with readdir() in such a way that the file is left out completely.
But a "corrupt" file is highly unlikely, and two different backups
missing the same file seems absurdly unlikely even if you are trying
to make it do so.  (Also, if multiple files are
committed/tagged/etc "at the same time", the backup might
randomly get some pre-updated and some post-updated...)

Erik Christiansen's idea (updating uid/gid/permissions) is
is fairly good.  Although if you tweak the permissions a
bit and use a "LockDir", you could leave read-only access
enabled while the backup is running.  Also, a CVS opreration
might fail in a reasonably safe way (leave stale locks and
temporary files) if you change the permissions CVS is
updating files.

                   - Matthew

On Wed, Mar 25, 2015 at 08:33:18AM +0000, Saleh, Mai wrote:
> Hi Mathew , 
> 
> Thanks for your reply 
> I just needed to prevent write operation will taking a backup , could you 
> please tell me what would be the risk of taking a repository back while not 
> preventing a write to it will the whole repository be corrupted or only the 
> files that was being written during backup operation 
> 
> 
> 
> 
> Thanks & BRs
> 
> Mai Saleh
> IT Global Technologies & Infrastructure
> Software Tools Engineer
> 
> 
> -----Original Message-----
> From: Matthew Ogilvie [mailto:address@hidden 
> Sent: Wednesday, March 25, 2015 7:58 AM
> To: Saleh, Mai
> Cc: address@hidden; address@hidden
> Subject: Re: CVS lock script
> 
> > Date: Tue, 24 Mar 2015 07:41:50 +0000
> > From: "Saleh, Mai" <address@hidden>
> > To: "address@hidden" <address@hidden>
> > Subject: CVS lock script
> > 
> > Hi ,
> > 
> > I need to know is there any open source lock and unlock cvs repository  
> > script that can be used by corporates for free
> > 
> > Thanks & BRs
> > 
> > Mai Saleh
> 
> It may depend on exactly what you mean by locking a cvs repository.
> 
> In most cases it is probably easier to either manually configure existing 
> facilities (or write a short shell script to do so), rather than try to find, 
> learn, and configure some third party script.
> 
> For example:
> 
> CVSROOT/commitinfo or other *info hooks might be useful for complex access 
> policies.  I may have seen a reference years ago to a third party 
> configurable script you can reference from here to make it easier to 
> configure branches/directory access, but I don't remember the name...
> 
> CVSROOT/config includes a "LockDir", which if defined would allow you to use 
> file system permissions (owner, group, mode) to control access at a directory 
> level within the main repository, including read-only and/or no access.  
> [This is for temporary locks while CVS is processing a directory; it needs 
> those locks even if it is doing a read-only operation...]
> 
> If you just want to have a stable version for several operations, maybe just 
> use branches and/or tags appropriately?
> 
> If you use pserver access, you might be able to temporarily disable all 
> access by tweaking a line in an xinetd or inetd config file...
> 
> Or temporarily disable all access by altering the permissions on just the top 
> level directory of the repository.
> 
>                         - Matthew Ogilvie
> 
> P.S.: On a tangent, have you considered upgrading to a newer tool?
> Subversion has a similar UI and is often considered somewhat more modern.  
> Also, while tools like git and mercurial have a steeper learning curve, they 
> are significantly more flexible.  The main reason I haven't gotten around to 
> to unsubscribing from this CVS list is that the traffic has dropped to nearly 
> 0...