RE: CVS lock script

Hi Mathew ,=20

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

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

Thanks & BRs

Mai Saleh
IT Global Technologies & Infrastructure
Software Tools Engineer


-----Original Message-----
From: Matthew Ogilvie [mailto:[email protected]]=20
Sent: Thursday, March 26, 2015 7:23 AM
To: Saleh, Mai
Cc: [email protected]
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 th=
ere 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 o=
preration might fail in a reasonably safe way (leave stale locks and tempor=
ary 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 ,
>=20
> Thanks for your reply
> I just needed to prevent write operation will taking a backup , could=20
> you please tell me what would be the risk of taking a repository back=20
> while not preventing a write to it will the whole repository be=20
> corrupted or only the files that was being written during backup=20
> operation
>=20
>=20
>=20
>=20
> Thanks & BRs
>=20
> Mai Saleh
> IT Global Technologies & Infrastructure Software Tools Engineer
>=20
>=20
> -----Original Message-----
> From: Matthew Ogilvie [mailto:[email protected]]
> Sent: Wednesday, March 25, 2015 7:58 AM
> To: Saleh, Mai
> Cc: [email protected]; [email protected]
> Subject: Re: CVS lock script
>=20
> > Date: Tue, 24 Mar 2015 07:41:50 +0000
> > From: "Saleh, Mai" <[email protected]>
> > To: "[email protected]" <[email protected]>
> > Subject: CVS lock script
> >=20
> > Hi ,
> >=20
> > I need to know is there any open source lock and unlock cvs=20
> > repository script that can be used by corporates for free
> >=20
> > Thanks & BRs
> >=20
> > Mai Saleh
>=20
> It may depend on exactly what you mean by locking a cvs repository.
>=20
> 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 fi=
nd, learn, and configure some third party script.
>=20
> For example:
>=20
> CVSROOT/commitinfo or other *info hooks might be useful for complex acces=
s policies.  I may have seen a reference years ago to a third party configu=
rable script you can reference from here to make it easier to configure bra=
nches/directory access, but I don't remember the name...
>=20
> CVSROOT/config includes a "LockDir", which if defined would allow you=20
> to use file system permissions (owner, group, mode) to control access=20
> at a directory level within the main repository, including read-only=20
> and/or no access.  [This is for temporary locks while CVS is=20
> processing a directory; it needs those locks even if it is doing a=20
> read-only operation...]
>=20
> If you just want to have a stable version for several operations, maybe j=
ust use branches and/or tags appropriately?
>=20
> If you use pserver access, you might be able to temporarily disable all a=
ccess by tweaking a line in an xinetd or inetd config file...
>=20
> Or temporarily disable all access by altering the permissions on just the=
 top level directory of the repository.
>=20
>                         - Matthew Ogilvie
>=20
> 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, t=
hey are significantly more flexible.  The main reason I haven't gotten arou=
nd to to unsubscribing from this CVS list is that the traffic has dropped t=
o nearly 0...