RE: CVS lock script

[Saleh, Mai]

Hi Mathew , 

Thanks a lot for all your answers and help :)
Just one more question 

What would be the best method to backup CVS repository daily full , or daily 
differential then weekly full ?
As in svn  differential is not recommended due to some hook scripts reasons 

Thanks & BRs

Mai Saleh
IT Global Technologies & Infrastructure
Software Tools Engineer


-----Original Message-----
From: Matthew Ogilvie [mailto:address@hidden 
Sent: Thursday, March 26, 2015 7:23 AM
To: Saleh, Mai
Cc: address@hidden
Subject: Re: CVS lock script

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...