CVS lock script

[Saleh, Mai]

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

[Matthew Ogilvie]

Date: Tue, 24 Mar 2015 07:41:50 +0000
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...

[Saleh, Mai]

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:***@mailcan.com]
Sent: Wednesday, March 25, 2015 7:58 AM
To: Saleh, Mai
Cc: ***@mailcan.com; info-***@nongnu.org
Subject: Re: CVS lock script

Date: Tue, 24 Mar 2015 07:41:50 +0000
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...

[Erik Christiansen]

Post by Saleh, Mai
Hi Mathew ,
Thanks for your reply
I just needed to prevent write operation will taking a backup ,

^^^^
while

The following assumes that the repository is on a unix box of one
flavour or another, and that it is adequately backed up, so that a
fumble is not fatal.

If the repository is given e.g. the group "developers":

# chgrp -R developers <path_to_repository>

and all developers allowed access gain that by being made members of
that group, then they can temporarily be locked out with:

# chmod g-wx <path_to_repository>

I.e. On a directory, execute permission is navigate permission.

When the backup is complete:

# chmod g+wx <path_to_repository>

If the repository is owned by an exclusive account, then that can be
used instead of root, and that would be less risky in the event of
mistakes.

Over several decades, the only measure I took to ensure a static
filesystem during backups was to have cron run them at 3 a.m.
when none of my developers would be there. It is, however, trivial to
add the two chmod commands to a backup script.

You just need to be there in the morning to run the second chmod
manually if something goes wrong halfway through the backups.
(Though a few hours of delay in being able to check in is usually OK)

Erik

[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

Post by Saleh, Mai
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-----
Sent: Wednesday, March 25, 2015 7:58 AM
To: Saleh, Mai
Subject: Re: CVS lock script

Date: Tue, 24 Mar 2015 07:41:50 +0000
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.
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...

[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:***@comcast.net]
Sent: Thursday, March 26, 2015 7:23 AM
To: Saleh, Mai
Cc: info-***@nongnu.org
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

Post by Saleh, Mai
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-----
Sent: Wednesday, March 25, 2015 7:58 AM
To: Saleh, Mai
Subject: Re: CVS lock script

Date: Tue, 24 Mar 2015 07:41:50 +0000
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.
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...