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

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

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

(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.

(Log in to post comments)

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.