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

Re: user private groups and a src group



Remy Card card@masi.ibp.fr writes in part
> Matthew Birkholz birkholz@martigny.ai.mit.edu writes in part
> >    Date: Wed, 16 Mar 94 16:43 PST
> >    From: "Remy Card" <card@masi.ibp.fr>
> > 
> >    [...]
> > 
> >          Now, let's think carefully about a common project development
> >    involving a team of cooperating users.  If the users all share
> >    read-write access on the project files, there is a great risk of
> >    inconsistency (users A and B can modify the same file and the changes
> >    made by A can be overwritten by the changes made by B).  In this case,
> >    the write access can be a *very* *bad* thing and is not an advantage at
> >    all.
> > 
> > RCS handles the file permissions correctly (most of the time), assuming
> > everyone in the project has write access to the directories.  You should
> > try it sometime.  It's quite slick.  When a file is not checked out, the
> > permissions are read-only for everyone.  When a file is checked out
> > (locked), the owner of the file becomes the person who checked it out and
> > the permissions are owner read/write, group read-only.  There is no *very*
> > *bad* thing to worry about -- other than getting the group permissions on
> > the directories right.  (I think we've come full circle, again.)
>  
>         That's exactly my point.  With RCS, there is no bad inconsistency risk
> to worry about since the shared files are kept as read-only in the repository.
> On the contrary, if you don't use any version control system and set write
> permission for a team on every source file, there is a risk of concurrent
> access which can lead to work loss.

If you don't use any version control system then you deserve what you get.
If you give write permission to people you can't trust to at least negotiate
with each other before they edit, you deserve what you get.

As Matt Birkholz points out, RCS handles our scheme quite well: only
the person who checks out  the file gets write permission even if
the umask is 002.  (I just checked before I read his message, as well.)

> >       On the contrary, if you provide the developers with read-only
> >    access [...]
> > 
> > I doubt that having _no_ write access is a solution.
>  
>         Please, re-read my mail.  I talked about read-only access to the files
> stored in the repository.  Obviously, a developper needs write access to
> a copy of these files if he wants to modify them.  Note that RCS sets
> write access to the working file after a checkout.

Yes, but ONLY for the one who checks it out!  So, how does it affect
our proposal?

--
	-Matt Hannigan


Reply to: