Vesta Releases First GPL Version
Eugenia writes: "Many are the developers who prefer Perforce in favor of CVS. There is a new player in the field now though. It is called Vesta and it is a replacement for both CVS and 'make'. It handles source revision control and automated construction. It is the result of over 10 years of research and development at the Compaq/Digital Research Center. Just last August Compaq gave the 'ok' to GPL Vesta and since then the 4-member team worked hard to finish up the port to x86 Linux (prior to that, Vesta only worked on Alpha and Tru64 systems). Now, the first Free version is available for download. For a summary of some of the features that make Vesta interesting, see this page."
CVS does have some problems. In particular, there should be a way of checking in all the files of a change at once, and having the check in built to see if it actually works properly. The complete check in should be an ACID transaction. There should also be nicer ways of browsing the repository. Comparisons between the systems are few and far between. I've never seen a good one. But that's like most tools because most of these questions wind up being quite specific to the task at hand. But really high quality technical comparisons are really hard. I've written poor ones myself and had to admit that what I'd looked at did not really capture the differences. One's I've had to deal with recently are Direct 3D vs OpenGL, Visual C++ .NET vs Borland. And even thinking about language comparisons makes my head hurt. There are reports in other fields ( think Jane's ) that are really high quality and high cost.
But anyway - if you do the comparison it'd be great to see it up on a web page.
Well, for one, some of CVS's "authors" (karl fogel is a big name in CVS circles) are the very same people that started subversion to solve CVS's problems. There are a number.
The biggest 3 problems, in my experience, with CVS are binary files, [lack of] atomic commits, and branching.
Binary files, for better or for worse, get checked in all the time. Having to tell CVS that it's a binary file (and having it hose the binary if you forget) is a PITA. It's much better to assume everything that isn't immediately recognizable as text is a binary. (this is what perforce and subversion try to do, and they both do a good job from what I've seen.)
Anyone who's ever done CVS style branches and then tried doing it the way perforce and subversion do it will tell you that the latter is far preferable. If you aren't familiar, perforce and subversion both work by doing brances as lazy copies (with history pointers) in the filesystem namespace. This make life easier. It also simplifies file revision #'s.
Atomic commits aren't a big deal when there's only one developer (or one developer per given piece of code.) But as soon as several people start developing it can get messy. With atomic commits, since an entire set of changes succeeds or fails, you eliminate the hassle of corrupted code for the most part.
I, for one, really like perforce and can't wait for subversion to be released. It looks to have the best of both worlds.