[Linux-cluster] Subversion?

Kevin P. Fleming kpfleming at backtobasicsmgmt.com
Mon Aug 23 15:49:26 UTC 2004


Daniel Phillips wrote:

> I was just taking a look at this article and I thought, maybe this would 
> be a good time to show some leadership as a project, and take the 
> Subversion plunge:
> 
>    http://www.onlamp.com/pub/a/onlamp/2004/08/19/subversiontips.html

I am part of another project that recently switched to Subversion, and 
we like it quite a bit. It's a major improvement over CVS.

> Subversion is basically CVS as it should have been.  It's mature now.  
> The number of complaints I have noticed from users out there is roughly 
> zero.  Subversion _versions directories_.  Etc.  Etc.

Yes, and if you haven't already, read the first few chapters of the 
"redbean" Subversion book to get a feel for how it works. 
Branching/tagging is painless and low-cost (including dropping dead 
branches/tags, something that CVS can't do well at all), there are cool 
methods to include parts of the repository inside other parts at 
checkout time, etc.

> The only negative I can think of is that some folks may not have 
> Subversion installed.  But that is what tarballs are for.

Subversion is an easy install. There is another negative, though: the 
current release of Subversion uses Berkeley DB as its storage means, and 
we've had problems with it getting randomly locked and causing issues. 
We don't know if this is due to running ViewCVS against the repo as 
well, or what else it may be. Given the problems we've had, we are 
anxiously awaiting the 1.1 release of Subversion that will have a 
filesystem-based backend, rather than bdb.

> Our project development is not highly parallel at this point, so our 
> repository serves more as a place for maintainers of the individual 
> subprojects to post current code.  So there isn't a great need for a 
> distributed VCS like Bitkeeper or Arch.

I also like BK quite a bit, and it has one major advantage over 
CVS/Subversion: you can have local trees and actually _commit_ to them, 
including changeset comments and everything else. This is very nice when 
you are working on multiple bits of a project and are not ready to 
commit them to the "real" repositories.




More information about the Linux-cluster mailing list