[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Strict Locking for checkouts

From: David H. Thornley
Subject: Re: Strict Locking for checkouts
Date: Tue, 13 Feb 2001 17:18:34 -0600

address@hidden wrote:
>         I need to stablish a strict lock on each checkout on my repository,
> and then, when a user try to checkout a locked file, I need to denie
> access.
Why?  What are you trying to accomplish by this?  As it stands,
CVS won't do what you say you need to do.  Since CVS has
been around for quite a few years, it would be reasonable to
think that was by design.

> 1- How can I automate the strinct locking creation? I cant not rely on
> users for this, I need some automated method to lock on each checout.
Write wrapper scripts and tell the users to use those?

One problem here is that CVS has no operation that really
corresponds to a locking system's checkout.  You could look
at "cvs edit" and "cvs watch".  You can force all checkouts to
be of read-only files, and tell the users to use "cvs edit"
to change the permission.

In my experience, strict locking will buy you precisely nothing
over good communications.  Writing "I'm working on this, let
me know if you need to - David" in the master listing book
worked even better than having SCSS locks.

> 2- As I see rsclock only works for checkins.. how can I do to make
> this work on checkouts? In my implementation a user can not checkout a
> file if another user is working on it.
Why not?

In some systems, there is a distinction between checking out a
file, thereby getting a copy and sole permission to change that
file, and some sort of copy, which gets a copy and no permission
to change the file.  In CVS, there is no such distinction.

If you really want to stop people from getting copies of files
other people are working on, then try some other system, because
CVS won't work for you.

Simply, CVS was designed to get away from this sort of
restriction.  The idea of merging changes together without
locks has proved very successful on many projects.  Why would
it not work on yours?

David H. Thornley                          Software Engineer
at CES International, Inc.:  address@hidden or (763)-694-2556
at home: (612)-623-0552 or address@hidden or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]