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
> From: "Saleh, Mai" <Mai_...@mentor.com>
> To: "info...@nongnu.org" <info...@nongnu.org>
> Subject: CVS lock script

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

[Erik Christiansen]

On 25.03.15 08:33, Saleh, Mai wrote:
> 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

--
manual, n.:
A unit of documentation. There are always three or more on a given item.
One is on the shelf; someone has the others.
The information you need is in the others. - Ray Simard

[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

[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