[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Subversion?

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:


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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]