See here.
I recognize that some of the problems are painful for complex or heavily used development environments, but the ubiquity, the tools, the documentation makes it an obvious big win for most projects, doesn't it?
Where I work, I'm going to be forced to start using CA's Harvest, which looks pretty involved, especially for small projects. Anybody have any comments or experience on this product?
Re:Isn't CVS the first choice for most OS projects
ziggy on 2003-10-24T21:41:34
I've given an intro-to-CVS talk for a few user groups over the years. I'm constantly amazed at how many developers are working with significant bodies of code without version control.Based on this comparison and other information I've seen, doesn't it just make sense to choose CVS for most OS projects?Then again, using version control wasn't the norm 10-15 years ago. And a lot of Perl programmers aren't professional developers, so CVS is just another entry on the "list of things I gotta learn" for many newbies.
I describe CVS as the "gold standard" of version control. It's not the best, but it is certainly very capable. Better systems address some deficiency of CVS in one edge case or another. For general (lightweight) use, it's all you need most of the time. It's also a good choice in the general case, because it's so widely used, well understood, extensively documented, and supported by so many tools.
Re:Just another subversion convert...
IlyaM on 2003-10-27T09:30:24
Maybe I'm just looking for perfection. I defentely was spoiled by trying bitkeeper. To me subversion looks like just a small improvment over CVS. File renames and similar things are cool but I definetely can live without them - I will not switch to subversion just because of them. What I really need, what really whould save my and co-workers time is robust support for distributed development and robust handling of branching and merging. Subversion is nowhere close to that.Re:Just another subversion convert...
Adrian on 2003-10-27T10:32:32
I felt the same way, until somebody persuaded me to try it for a week. I now can't imagine going back to CVS unless forced. I really would give it a whirl - especially since you can now use the standalone svnserve server rather than having to muck around getting an Apache2 DAV server up and running.
I have to admit I try and avoid branch/merge at all costs since I find the reintegration pain worse than the avoiding-branching pain - but I understand that isn't always possible. Personally I prefer subversions branch/tag model. You get cheap branches and you avoid branch-point tagging since there is no branch/tag distinction, everything lives in the same space. Seems a much simpler model to me but YMMV.
On the distributed development one advantage is that you only get the diffs in any change sent over the wire which can make working with the repository much faster.
Being able to associate arbritary meta-data with files and directories is interesting too. For example I'm playing with marking failing tests with meta-data and then preventing commits until the tests pass
:-) Obviously if CVS works for you go for it, but I really would give it a try.
