info-cvs
[Top][All Lists]
Advanced

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

More locking, sort of


From: cvs
Subject: More locking, sort of
Date: Thu, 5 Sep 2002 14:41:06 -0400

    From: address@hidden
    Date: Thu, 5 Sep 2002 13:03:59 -0500 (CDT)
    
[...]     
    > Set up a Unix group which has write access to the repository.
    > Ensure that everything in the repository is read-only to everyone
    > else, and ensure that the directories all have the setuid bit
    > so that newly created directories inherit these permissions.
    >
    There's a step missing here:  if you just do this the turkeys will
    be unable to check out and update software.  

Right.  As I was trying to describe previously, the issue is around a
small area of the tree.  In fact, it's the common makefile
infrastructure which drives the building of the whole tree; get that
wrong and you can bring everything to a screeching halt for everybody,
rather than just porking one particular subdir.

                                                 You need to put a line
    like
    
    LockDir=/usr/local/cvslocks
    
    (change the directory as you will, but don't put any spaces in)
    in CVSROOT/config, and of course have a /usr/local/cvslocks or whatever
    directory that all the turkeys can write to.  Assuming a reasonably
    up-to-date version of CVS, this will allow the turkeys read-only
    access to the repository.

Huh.  I suppose one could also play games with putting certain (sets
of) users in or out of certain groups, thus allowing some selectivity.
[...]     
    I suspect this is not going to fly, given the political problems against
    getting decent hackers.
    
    I still have qualms about this, most particularly being that I don't
    see that having competent people looking over incompetent code is
    a tremendous improvement.  Perhaps instituting different processes,
    such as early semi-formal reviews, would be more useful, but I know
    nothing of the politics at your site.

Yah.  The details aren't worth going in to, their effect it to render
the review processes (which we do have, and try to use) less effective
than they should be.

I grant that applying a technical solution to a political problem is
generally not the right thing, but in this case I have some control
over the former, and very little over the latter.

Thanks for the ideas.





reply via email to

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