Now that it's finally java-compatible (c.f. my recent posts in the general thread about getting the JDK into a virtual FS
), I'm going to suggest Vesta to you all. And especially to those not using an SCM at the moment - vesta takes only a couple of minutes to setup, and without the pains of CVS etc leaves many people with no good reason not to use an SCM
We think it's good enough that we've spent considerable time getting Vesta to work with java (more on why that's important below), and moving all our source code from existing systems onto Vesta; I'm only suggesting it here because I genuinely believe it is *that* good (and some here will probably remember how high my standards are for SCM's
). Anyone who tries it and wants the java integration stuff, just mail me and you can have it (it's very small, it just needed some serious debugging to get it to work
General reasons why you might want to move to Vesta:
- It's free (LGPL, on sourceforge)
- It's very easy to install and configure (compared to e.g. CVS). Just a couple of RPM's and answering a couple of basic questions.
- It was designed and written in-house to manage the DEC Alpha microprocessor development teams. This is not a toy project, it's a serious SCM that's been in commercial use for years (and is still in production use at Compaq and Intel on three continents).
- It has the features and the reliability that the big chip companies demand. Including lots of good documentation (although the FAQ is rubbish)
It's a bit different from most non-expensive SCM's, e.g.:
- It automatically mounts the repository into your filesystem - you can just "cd" into the repository directly, and read and execute your classes and JAR's without first checking them out (and you have all your normal shell commands and aliases)
- Replication of repositories was built-in to the original design; DEC Alpha had a dev team split between the west and east coasts working on the same code. Replication is very easy and designed to replicate hundreds of megabytes daily.
- Distributed builds were also built-in: setting up a "build farm" is easy, and gives you parallelized builds
- Compiling is done within Vesta. Yep, that's right - it does your compiling for you, as part of the build process. At first this might sound strange, but it means that every build is 100% repeatable.
- Every part of every build goes in a cache shared by every user - this is automatic distributed incremental builds. Builds tend to be very very fast (even more so when you have more developers).
The last two points are the most important. In C, the repeatable builds is a huge advantage (because there are so many libraries that introduce new bugs in successive versions). In Java this is less true, unless you use a lot of external libs - or do a lot of native compiling (note: no-one has made JET integration yet, although this could be a huge boon to JET developers if they did).
There is a big disadvantage, though: There currently isn't a server binary for Windows. This means you need a linux or unix machine to host the repository. Client access requires NFS which is usually built in to linux etc, and Microsoft made NFS a free upgrade for windows earlier this year. Some people also run samba to make the repository appear in windows networking (just as for mounting it in the FS: it means you can read and run classfiles, but you can't use this method to checkout/checkin without some extra jiggery-pokery).
FYI, before moving to vesta we had a hodge-podge of SCM's - CVS (buggy, prone to corrupting your source-code, slow, and difficult to setup new systems), RCS (less buggy, missing vital features such as checking-in whole packages at once: RCS can only check-in individual files, which gets VERY painful on large projects), and some half-breeds, part RCS, part CVS, part Windows-Explorer integration. I make no secret of my hatred of CVS (having nearly missed deadlines because of source-code corruption), and I know that a lot of people love it (fair enough, if it works for you). I don't want to start a flame-war, I'm only saying this as a disclaimer so that you're aware of my bias