Arch for CVS Users (Linux Journal) [LWN.net]

Arch for CVS Users (Linux Journal)

Posted Jun 2, 2004 17:41 UTC (Wed) by josh_stern (guest, #4868)
In reply to: Arch for CVS Users (Linux Journal) by iabervon
Parent article: Arch for CVS Users (Linux Journal)

The easiest setup if all developers are of equal priviledge is
to make a new special user for each given project and have the
special user own the repository. Every developer can then
login as the special user, for instance via sftp. Deveoper
identities are still preserved in the logs. But it would
be nicer and more flexible if Arch eventually supported ACLs
within its commit process.

(Log in to post comments)

Arch for CVS Users (Linux Journal)

Posted Jun 2, 2004 18:36 UTC (Wed) by moffixx (guest, #22010) [Link]

Arch's format is inherently log-structured. Changesets are just appended onto the archive. I'm not sure how fine grained you really want to get, but you can't forbid a checkin for one directory in an arch project while allowing all the others.

You can, however, restrict access on a per-project basis.

And if you really need stricter access control, then you probably want to do a more distributed method anyway. Have untrusted developers publish their own archives, and merge in from them what you feel is appropriate.

Arch for CVS Users (Linux Journal)

Posted Jun 2, 2004 19:34 UTC (Wed) by josh_stern (guest, #4868) [Link]

"you can't forbid a checkin for one directory in an arch project while
allowing all the others"

Of course it could work that way. A detailed error would be
reported, no checkin would occur, and the developer would find
an alternative strategy - e.g. a) decide she didn't really
need to modify that other directory, or b) get someone else
with the necessary priviledge to do the checkin.

Arch for CVS Users (Linux Journal)

Posted Jun 3, 2004 1:27 UTC (Thu) by mbp (guest, #2737) [Link]

Oh, you're talking about allowing some users to commit to say ./doc/ but not anywhere else in the source tree?

It's true that Arch can't directly support that, while Svn can.

I would think that the way to do this under Arch would be to have a separate branch in which the documentation developers can work. A working directory can be assembled from several trees using Arch config specs, which are kind of like CVS modules.

(In fact I suppose you could use CVS modules to allow per-directory commits, which I had not thought about before. Doesn't Mozilla do something like that?)

In some ways this seems conceptually cleaner. It is somewhat more complex to set up, but that only has to be done once, then copied into the checkout instructions.

On the other hand, I think it's a feature that Arch's version control is managed by OS permissions which are likely to be well-understood and stronger. You can also put the different branches on different machines, which might be a good idea if you really distrust those documentation guys.

The idea of access control means something different in distributed systems. On Subversion, somebody not trusted to commit to a directory can really work on it. In distributed systems, people who are not trusted to commit at the moment can still do their own work and submit it for consideration.