Re: user private groups and a src group
Matthew Birkholz writes:
> 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.
> 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.
> So, as a conclusion, IMO:
> 1. write access to a common set of files by a development team
> is not needed (and not even desirable) to achieve a project
> with efficiency,
>
> Does your revision control system run setuid=root or something? The RCS
> that came with Debian 0.91 doesn't. It can't write files to which it
> does not have write access.
Please take a look at the manual. From the `ci' man page :
ci never changes an RCS or working file. Normally, ci
unlinks the file and creates a new one; but instead of
breaking a chain of one or more symbolic links to an RCS
file, it unlinks the destination file instead. Therefore,
ci breaks any hard or symbolic links to any working file
it changes; and hard links to RCS files are ineffective,
but symbolic links to RCS files are preserved.
The same applies to `co' as well. To store a new version of a file
in a repository, co only needs write access to the RCS directories. The
write access to directories can be easily set when the directory tree
is created, I think. If you are too lazy to set group write access to
the directories, you can consider using CVS which sets this write access.
> 2. thus, there is no need for `non standard' umasks for members
> of the development team,
>
> Which standard is that? (I think you mean "non-customary" or
> "non-traditional".)
Sorry, `non standard' was a poorly chosen term. I was meaning
permissive umasks.
> 3. thus, I think that the uid==gid proposal is unneeded.
>
> uid==gid is a convenience. It is not needed to implement the proposal.
> Calling it "the uid==gid proposal" is a misnomer. Please stop it.
> If you are going to have a private group per user, what gid's would you
> pick? (Hint: "gid=random(uid)" is _not_ a good answer; "gid=identity(uid)"
> is a good answer.) (Double hint: That was a rhetorical question [and a
> rhetorical hint, I suppose]. :-)
OK. So, I correct my phrasing: I think that the private groups
proposal is unneeded.
> Of course, I'll be glad to hear about counter examples
> (important projects which cannot be achieved with the help of a version
> control system and which require a change in the uid and gid
> attribution).
>
> Well, _my_ project is "important" (to me) and so is my time. (Bye.)
So, why don't you explain why your project cannot be achieved
with a version control system? The proposal is supposed to solve the
problems related to development on shared files and I am quite amused
that none of its supported seemed to consider version control systems
before I talked about them :-)
> Matthew Birkholz
> birkholz@martigny.ai.mit.edu
--
Remy Card
card@masi.ibp.fr
"Build a system that even a fool can use and only a fool will want to use it"
Reply to: