See also: [Talk:WhyUseSubversion TalkPage]
Positive Reasons for using Subversion
Positive A: Subversion will allow ASF to start using signed SSL certificates instead of SSH to access the repository. This would reduce the need for account creation. [Less user accounts == more security, the most secure system is one with zero users....]
Positive B: Subversion appears to be some order of magnitude faster than CVS.
Positive C: Subversion is supposed to work through firewalls. Currently, you'll regularly see "I'm behind a corporate firewall and can't checkout...". This can be very inconvenient, both for ordinary users who had been told "This bug has recently been fixed in the repository" as well as for committers. [It verifiably *does* work through firewalls assuming there is WWW access from said firewall; otherwise how would be people browse the web? Thom] [If people are really unable to ssh out of their corp. firewall, but can HTTP/HTTPS - well we could create a tunnel from a http/https port to the cvs.apache.org ssh listener for them :-)]
Positive D: Features. Can you say "delete a directory" or "rename files"? And track the history for them? How about WebDAV access to the repository? Simple anonymous user access? Simplified tags and branches? (say, "cheap copies") Simplified merging? Hoo yah...
Positive E: Anonymous access is much easier. This may seem trivial to committers and members, but something like this will reduce the barrier for would-be contributors.
Negative aspects of Subversion
Negative A: Security: ASF has been using CVS for years, and ASF has experience dealing with cvs security, unix account security, auditing, etc. Jettisoning that in a day ( the JustDoIt attitude ) is not appropriate.
Negative B: Moving to SSL-based security, starting a CertificateAuthority, involves some heavy policy issues. Shouldn't this be something that the BoardOfDirectors decides - root certificates, security, etc, some of these issues could be considered "organizational". A CA isn't required for subversion, thats just FUD caused by a totally other discussion. Whats more the fact that the board should be deciding related policy, isn't a negative aspect of Subversion. Pretty weak argument and strong FUD coming from someone with a chip on their shoulder here?
Negative C: Tools support. CVS had a large number of tools, IDE integration, etc. Subversion is not so integrated. Take a look at the available reports for something like Maven. Many of those reports revolve around gathering usage stats from CVS.
Refutation of Positive Arguments:
Positive A Refutations: Negative B and Negative C both refute the validity of Positive A. Moving from SSH to SSL is change to an already tested security model, and the policy issues raised by SSL are something that needs to be looked into by the board as it is more than a technical decision.
Update: This is no longer the case as Subversion now supports SSH the same way CVS does
Refutation of Negative Arguments:
Negative A Refutations:
- Resistance to change for security's sake? Yes, ASF has years of experience in X, but that should not prohibit you from migrating to a superior system.
In some senses, ASF would be shifting the security responsibility from OpenSSH and CVS to ApacheHTTPDServer and ModSSL. Should I understand the argument to be that Apache with mod_ssl is "not to be trusted".
- This argument is now absolete because Subversion now have the same ssh tunneling capability as CVS. The same SSH based security infrastructure can be re-used for subversion if desired ( and have read-only WEBDAV access, for example ).
Negative B Refutations: Making such decicions may be necessary anyway. Setting up a CA and certificate management is certainly not a small job. However, certificates, once issued, can be used for many other purposes too:
- secure access to web based content management for the web sites
- other web based tools, for example mailing list management
- secure mail communication of the committers (remember the onslaught of faked and worm infested mails last year?)
Subversion doesn't require a CA. That may be helpful for other things, but in an SVN world, we simply want our own CA to pass out client certificates. The client certificates enable us to avoid keeping user/pass information on the server, and simply rely on the presentation of a client cert. The httpd server would have a cert to validate itself to the clients. Nowhere in this scheme are there any real heavy policy issues.
Negative C Refutations: There is a large community of tools already being built around Subversion, and it's library-centric design certainly makes it considerably easier to do so than for CVS. See, for example, TortoiseSVN http://tortoisesvn.tigris.org/ and other tools on the tigris.org site. Furthermore, use of Subversion by Apache will likely result in more IDE integration in a very short run.