Oddities and limitations

Buy CVS & Subversion Stuff!

Here is some experience about CVS oddities and limitations for collaborative development. These include CVS protocol rantings as well as ordinary setup problems. I hope this will be a useful base to analyse and develop future CVS implementations.

If you ever tried to find an optimal solution for collaborative open source development with people participating from any possible locations across the globe, you probably found that CVS is most widely used version control system. Although CVS is very powerful and I have quite addicted to it's merge, branching and annotating capabilities at the same there are many weaknesses and complexities, which doesn't allow one to use it effectively.

Consider the following scenario.

1. We have a shared web-hosting with openssh shell access to cvs.
2. We have some trusted developers and some unknown, who is willing to participate.
3. We choose early CVS access development rule, which means what any developer should receive an access to repository regardless of his/her skills or experience.
4. We provide control of changes made in repository "by fact", which means that all changes are monitored by ML where "approve" is silent and "deny" means making a rollback. Pretty much the way this wiki works.
5. We need a web-based interface to repository, located on different machine to work with CVS history, exchange links to key poins and diffs in this history.
6. We need to be able to submit a patch via web and get it's diff against target revision from CVS to review, we also need to be able to approve it and get commited from web in just one click. Although web-programming is not a concern of CVS itself, but this scenario can useful to rate how CVS is able to integrate with modern collaborative development environment.
7. All web software should not have shell access for obvious reasons.

The steps to build this environment are pretty straightforward and here are the limitations.

• We have a shared web-hosting with openssh shell access to cvs.

Leaving all the "why" reasons we have one shell account, which contains CVS repository in it's home directory. We also have different user account for web-server with it's own home directory, which contains html/php files for our domain. Web-server user doesn't have shell access - ftp only, but hosting allows outgoing connections. Shared web-hosting also means, what we can not maintain and compile our own CVS version (suppose developers doesn't have necessary C/unix skils) and do not trust any other CVS versions different from oficial installed on a server by hosting company.

• We have some trusted developers and some unknown, who is willing to participate.

We can't create shell account for every user, but we can use openssh ability to "force command" while authenticating each user with public key. In CVS case we need to add the key with some prefixed like "no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/bin/cvs --allow-root=/home/ourcvsuser/repository server" ssh-rsa AAAAB3NzaC1yc...8w== rsa-key-20051030" to .ssh/authorized_keys2 file. This command autoexecutes "cvs server" command for user, authenticated with this key regardless of what user want or specified. This way we try to limit user shell access to cvs operations only. The command --allow-root is used to limit user from creating new repositories or gain access to another repositories. Problem no.1 - cvs doesn't support --allow-root option with "server" command. The other side is what we need to setup cvs user name from the same openssh key. This is yet (to be investigated), because AFAIR there is no convenient way to do this without cvs patch/recompile, because CVS uses information about username from shell environment.

• We need a web-based interface to repository, located on different machine to work with CVS history, exchange links to key poins and diffs in this history.

This means, what we need some web-based implementation of CVS protocol, what would be able to list files and directories in repository, browse history and such. So far I've seen only one almost "web-based" CVS client implementation written purely in Java. All other scripts use shell cvs command or C code. This way we seem in need to invent the bicycle, because there is no way to stick with CVS and continue development with friendly and secure web environment/front-end. Ok, let's try and develop at least R/O protocol in PHP. The functionality we need: 1. Get list of modules on repository for which we have access (we can get list of modules, but AFAIR can not limit the listing) 2. Get list of files and directories within these modules (see CVS_FAQ - our hosters, of course, use old stable 1.11.x branch, so we need to do some protocol command like "cvs rdiff -s -D 01/01/1971 -r $rev $mcode" or "cvs history -c -a -l" and parse it's output). 3. We also need to be able to store information about changes in repository and incrementally refresh it from web-scripts (AFAIR cvs doesn't allow to get the date of latest modification to repository or a list of all changes since particular date without sending all Entry/Modified/Directory stuff, which is a waste of traffic and time to implement for our read-only service).

perhaps to be continued.. feedback and proposals are welcomed --Techtonik 09:44, 19 Nov 2005 (EST)