Why not upgrade CVS? Subversion, GNU Arch, etc. [LWN.net]

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 3, 2004 1:02 UTC (Thu) by mbp (guest, #2737)
In reply to: Why not upgrade CVS? Subversion, GNU Arch, etc. by piman
Parent article: Arch for CVS Users (Linux Journal)

Both Arch and Subversion require "a lot" of configuration and dependencies if you want fine-grained access controls, e.g. Apache + DAV.

I don't think that is true for Arch. I have different branches with different visibility simply by publishing them on public web sites, private web sites, or not at all. I don't allow anyone to directly commit to my archives and that works fine. There is no DAV involved, and only Apache 1.3.

What configuration do you suppose is needed?

(Congratulations on spelling "a lot" correctly though. It certainly raises the tone compared to Slashdot. :-)

(Log in to post comments)

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 3, 2004 6:22 UTC (Thu) by piman (subscriber, #8957) [Link]

I don't consider flat-out refusing others to commit to your archive fine-grained. I do realize that it fits much better with some of the development models supported by Arch, and so is a more realistic possibility than with Subversion (where such a situation would essentially result in no developers sharing revision information at all).

Personally I see value in having many people able to commit to the same repository. This can be done with Arch or Subversion, but it requires more configuration than just SSH to do properly for both of them. To say that Arch doesn't require any server configuration (like dmarti) did is technically true, but you can make the same claim for SVN - in both cases, for the limited, one-committer, private archive situation. Even in your case, there's some server configuration involved in publishing the Arch changesets appropriately.

Why not upgrade CVS? Subversion, GNU Arch, etc.

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

So what do people mean by "fine-grained"? Finer than branches? Do you want to limit which directories or files can be touched?

The thing is this: anyone who I would trust to have SSH access to my machine and to commit to a branch, I would trust to commit to any file within that branch. If they suddenly turn bad, being able to commit anywhere is enough to cause trouble. I can't think of many cases where I want to allow people to write to only particular files in a project.

I can certainly imagine people only being able to write to one project and not another, or to one branch but not another. But Arch accomodates those uses just fine, and without requiring as much configuration as Svn. Just chgrp/chmod the directory and you're done.

> This can be done with Arch or Subversion, but it requires more
> configuration than just SSH to do properly for both of them.

I don't think that's correct. What were you thinking of?

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 3, 2004 6:44 UTC (Thu) by piman (subscriber, #8957) [Link]

(I realize that one significant thing I was forgetting was that in Arch, branches are not (necessarily) directories. In Subversion, they are, and I was conflating branch permissions with directory permissions unconsciously. Sorry.)

I am more interested in the case where I am some user on a system, without root access. I have some repository/project that the admin has set up for me, and I want to be able to authorize people to read from and commit to it. I want to do this as easily as possible, without having to bug the admin whenever I want to change a user's permissions.

I cannot see a way to do this with Arch or Subversion, period, without setting up some sort of (non-SSH) server.

One serious problem any SCM will run into with SSH-based access, at least if it is used on huge "communities" like SourceForge, is that Linux only allows 32 groups per user. I can't really fault Arch for this, but it does mean that some alternate authentication methods will have to be looked at.

Why not upgrade CVS? Subversion, GNU Arch, etc.

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

Ah, OK. So with subversion, people can write through the DAV module and be authenticated as a user that does not exist as a system user. That is a good feature.

I think setting that up to be secure is going to be more work than configuring either svn+ssh or arch+ssh, and I personally would feel less comfortable that it is secure.

Although Arch does not take this quite as far as Subversion, it does not require one OS-level uid per committer. For something like SF, you might be better off with one uid per project, and multiple SSH keys.

I can think of a few ways to solve your problem, depending on the details. The first question would be, why do you want other people to be able to commit to the repo? Let's suppose the answer is that you have several developers, you all trust all each others changes and nobody wants to be the gatekeeper or integrator.

What I would probably do is let every developer have their own archive. On the "head" archive, I would have a script that regularly tries to pull in changes from each developer, and maybe only commits to head if they compile/pass the test/whatever.

I guess with Subversion you could set up your own DAV server on a high-numbered port, but frankly I'm not sure that is something you should be doing without the administrator's permission. Most admins on net-connected machines don't appreciate it when people start complex servers listening for connections without the admin's permission.

You could get to a similar situation with Arch by running your own ftp server on a high-numbered port, limited to the appropriate directory. I would be a bit nervous about doing that, but it is not inherently any more risky than the Svn server. This would let people directly commit to the archive, etc.

(Can you start sshd as non-root? The protocol would allow it in principle, but I don't know if it works...)

> One serious problem any SCM will run into with SSH-based access,
> at least if it is used on huge "communities" like SourceForge,
> is that Linux only allows 32 groups per user.

Right, and SF hit this bug with CVS a while ago.

I think the whole idea of having one machine with tens of thousands of users is pretty bad to start with. The security implications are horrible, and in fact I read some project's horror story the other day about a rogue user deleting their files. With Arch you don't *have* to have one centralized machine for the whole world. It solves the SF problem at a deeper level.

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 3, 2004 11:15 UTC (Thu) by job (subscriber, #670) [Link]

ACLs? (Rant below.)

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 3, 2004 12:40 UTC (Thu) by Wol (guest, #4433) [Link]

Nobody's mentioned BitKeeper ... it sounds to me like Arch is meant to be similar in principle.

I do not want ANYONE updating my archive. And the central project archive should only be updated by ONE person (or a group agreeing amongst themselves).

Linus uses BitKeeper because he can give everyone *read* access to his tree and they keep themselves up-to-date. He has *read* access to other peoples' trees and can update his system from theirs as he sees fit.

I get the impression Arch is designed to work the same way - you need one person keeping the master repository up-to-date by *pull*ing from the developers, and the developers keeping up-to-date by *pull*ing from the master.

If you think in CVS terms you won't understand what the hell is going on, because CVS is a *push* system - the deverloper pushes updates to the central repository.

Cheers,
Wol

Why not upgrade CVS? Subversion, GNU Arch, etc.

Posted Jun 4, 2004 1:46 UTC (Fri) by josh_stern (guest, #4868) [Link]

I hate to sound ungrateful and demanding, but for using the pull
model it would be nice to have an integrated email push of the
comment logs. I'm not familiar whether bitkeeper provides such
but I haven't come across such a thing in the docs for arch.
Yeah, I know it wouldn't be too hard to hack up an alternative
interface for oneself...so I'm just giving feedback that this would
be a desirable feature add-on.