Slashdot Mirror

If you actually care about your code and making proper releases, use Vesta. Transparent version control that even tracks changes between proper check-ins (real "sub" versions). Built-in build system that beats the pants off of Make. It even has dependency tracking to the point that you not only keep your code under version control, but the entire build system. That's right. You can actually go back and build release 21 with the tools used to build release 21. It's sort of like ClearCase but without all the headache. Did I mention it's open source?

The first time I used Vesta, it was a life-changing experience. It's nice to see something that isn't a rehash of the 1960s

Unfortunately, a lot of the alternatives are like, "let's make something new, that's going to suck for the near future until we get the kinks worked out." Sure, they'll eventually become something great but for the present they're not really appropriate for a major project like KDE.

Well, I can't speak to the maturity of the others, but Vesta is the result of over a decade of R&D and has been in production use for microprocessor design projects at Compaq and Intel for over 6 years. Vesta's period of "trying something new" happened a long time ago, and the kinks have been worked out for years.

That's not to suggest that it's static (Intel employs two full-time software engineers to work on it), but it's been stable for a long time.

Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.

It's too bad they didn't chose something more advanced like Vesta, or Codeville, or monotone, or Darcs.

...Linus didn't discover Vesta before he started implementing git. The core of the two are very similar.

• Linus said "git is not an SCM. it's a filesystem designed to host an SCM". The Vesta repository is a filesystem. It has a versioning system (and a builder) built on top of it.
• git's backing store is indexed by a hash of the file contents, just like Vesta's.
• git stores complete copies of files, but only one copy of each file, just like Vesta.

Of course there are some important differences. Like the fact that Vesta's been around for over a decade, and has been in production use for microprocessor design at Compaq and Intel for over 6 years.

There are lots of such tools, including CVS, Subversion (SVN), GNU arch, Monotone, Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Superversion, Codeville, Bazaar, Arx, and Bazaar-NG.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

My first thought on reading the OP was "If they don't have the expertise to port a small build environment they built themselves, in-house to Windows then why do they think they have a hope in hell of porting their application?"

I have some trivial build scripts (bash) that check out a copy of the current source tree from the central CVS repository over ssh, setup a clean build environment, build the application (using a mix of qmake+make and cons) and run some basic regression tests.

I'm using the same scripts on Solaris, Linux, FreeBSD, MacOS X and Windows. On Windows they run under Cygwin, elsewhere under bash. There's some conditional stuff in the qmake files and the Construct files that sets compilers and commandline flags correctly (using Forte on Solaris, cl.exe from Visual C++ on Windows and gcc everywhere else).

It all works fine under cygwin. It took a little tweaking with environment variables to make everything happy (Cygwin + VC++ needs some configuration), but took less than a day to get running cleanly.

Combined with a central bash script that spawns a build on each machine (via ssh), takes the built and packaged result and uploads it to the distribution server it means I can release a build of all five architectures I support from a single source tree with a single command. I'm not using multiple machines for each architectures build farm, but that could be plugged in using distcc on some architectures fairly easily.

Invest a little time in making your build environment platform agnostic and it'll all run nicely. Unless money is very tight use a commercial compiler on Windows - Visual C++, Intel, maybe Borland - the quality of code generated is somewhat better than cygwin/gcc or mingw, the compile times are vastly better, and the pain in getting it to work well in a production environment a lot lower - due to the better "impedance match" between the compiler and the win32 tools. You'll only get the full advantages if you also use a cross-platform development library too - I use Qt, but wxWindows is pretty good for the cheapskates.

My actual development environment is emacs, bash and make/nmake. It's identical on Windows and the unixen. The fastest build environment is VC++ on Windows (due to better pre-compiled header support and a native compiler). The best for debugging varies depending on what I'm doing (Linux has valgrind and friends. Solaris has the Forte debugger which integrates with emacs very nicely). The same environment is installed on my PowerBook, so I can take the code offsite too, as long as I have occasional ssh access to the CVS server. As I'm building from a single source tree I can do 98%+ of the work on whichever platform is more comfortable and only very rarely have to worry about building debugging on a specific platform. QA is another matter, of course, but again the vast majority of bugs are in the platform independent code.

For C/C++ coding... If I was doing windows-only coding I'd strongly consider using Visual Studio, with embedded Emacs and some CVS (or revisions control system-du-jour). If I were doing Linux+Solaris-only coding I'd almost certainly use Vesta and either emacs or, perhaps, eclipse. For Mac-only XCode or, perhaps, eclipse would be the way to go.

But I don't foresee myself ever working on a single platform application again. And if I'm using native code (as opposed to, say, tcl or perl or python or even something that compiles to a JVM) I'll use the best system that runs cleanly on all those platforms. Right now that's emacs, Qt, perl+cons and a commandline compiler, IMO. And it scales fairly nicely if you have a decent source control system - CVS isn't that decent, but it works for small teams. For bigger teams I think you need a dedicated build engineer to handle source control and release anyway, but that's a whole other story.

It isn't and it won't be for a forseable future. But my gripe is really with developers that don't think cross-platform from the start. Another very interesting CM project is Vesta which also cannot run in a Windows environment.

The reason for not supporting Windows for both of these projects is probably that they are so old (10+ years) that Windows was not really regarded not to mention used as a serious development system. This situation changed with Windows NT4 and more so with Windows 2000 which is my OS of choice these days (that may change back if/when MS licensing terms become too much hassle, though).

Vesta is great, but even though it's GPL, it still requires the STARLA libraries, which are only available on VMS/OpenVMS.

I can only assume you're talking about some other Vesta from the one I'm familiar with, because:

1. It runs just fine on Linux (x86 and Alpha, PowerPC in the works).
2. I have no idea what STARLA is (and since I'm Vesta's primary maintainer/build master I think I'd know).
3. AFAIK, Vesta (at least Vesta-2, which is the free software version) never ran on VMS. (It uses NFS and chroot, so I'd be really surprised to see a VMS port.)

There's also Vesta, which has some pretty cool features

There's also Vesta, which has some pretty cool features

A couple other posts have mentioned Vesta, which goes a long way towards meeting the requirements you lay out. (For the sake of disclosure, it's only fair to mention that I am currently the primary maintainer of Vesta, and am somewhat responsible for getting it released as free software.)

1. atomic commits - your change happens only if all the files can be processed. This prevents a corrupted workspace when CVS processes half your files in a commit and then exits on an error throwing the other half of your files on the floor.

Vesta absolutely does this.

2. change list management - all commits have a unique reference number. CVS process files by directory instead of by workspace, so it is impossible to tell which files are associated with a commit.

Vesta does not explicitly provide this, however it's very easy to get with a simple diff command. The Vesta repository has a filesystem interface which makes it possible to directly access all versions past and present. A simple diff -r will show exactly what changed between any two versions. The also has other fun uses (e.g. greping across versions).

3. access control by workspace or workspace directory - the ability to give certain users or groups access to certain workspaces or directories. Ideally, access control can be by done by bug id.

Vesta's access controls are essentially UNIX file permissions. Through the repository's filesystem interface, you can control who can read and write (commit new versions) at a variety of granularities with chown, chgrp, and chmod.

4. graphical resolve of conflicts - a graphical three-way diff is the only way to resolve complex conflicts

Vesta provides no direct help here, but again, because of the filesystem interface to the repository, it's easy to apply standalone diff/merge/conflict resolution tools.

5. The ability to move files and directories and maintain file history and label integrity from the client. CVS requires the whole workspace to be locked so that moves can be performed on the server side and does not maintain label integrity.

Vesta's unit of version control is a directory. Between versions, files and subdirectories can be added, removed, renamed, etc.

6. web viewer and graphical difference viewer - the ability to browse via the web change set lists to see what files changed and what the actual differences were.

Not built-in, but already implemented on top.

7. the ability to integrate workspaces across projects - the ability to arbitrarily merge/integrate any source code from any project to any other project.

Vesta includes sophisticated cross-site features, including replication and remote checkout/checkin. It's been successfully applied before by a team spread across the US east and west coasts with hundreds of megabytes of sources.

8. powerful labeling features (parallel development and prior version support).

9. rollback or undo multiple changes - this is great way to recover from a developer commit disaster.

Vesta really shines in these areas. Vesta is also a build tool, and every build neccessarily includes a complete specification of the set of immutable versions it uses. Builds are also themselves immutably versioned. This makes it easy to determine which source componenets have changed between two versions of a build. Also, since it's as easy to select any historical version as it is the latest one, rolling back changes is trivial.

10. multi platform support - must run on all platforms.

We're still working on it (at the moment just Linux and Tru64 work), but hey, it's free software, and we'd love to have more developers/porters.

11. command line and graphical interface. Command line for scripts and graphical interface for those who can't work without it.

At this point there's a command-line interface and some rudimentary support for repository operations in the web interface. Again, it's free software, and we'd love to have somebody contribute more layered tools.

12. push and pull notifications - built in support for e-mail and news group notification of changes in the workspace.

Nothing built-in yet, but we've been talking about doing it, and it may happen soon.

There's a short summary of Vesta's excellent capabilities on it's web site (which includes several points not mentioned here), that I would recommend anybody interested in better version control/configuration management check out.

A couple other posts have mentioned Vesta, which goes a long way towards meeting the requirements you lay out. (For the sake of disclosure, it's only fair to mention that I am currently the primary maintainer of Vesta, and am somewhat responsible for getting it released as free software.)

1. atomic commits - your change happens only if all the files can be processed. This prevents a corrupted workspace when CVS processes half your files in a commit and then exits on an error throwing the other half of your files on the floor.

Vesta absolutely does this.

2. change list management - all commits have a unique reference number. CVS process files by directory instead of by workspace, so it is impossible to tell which files are associated with a commit.

Vesta does not explicitly provide this, however it's very easy to get with a simple diff command. The Vesta repository has a filesystem interface which makes it possible to directly access all versions past and present. A simple diff -r will show exactly what changed between any two versions. The also has other fun uses (e.g. greping across versions).

3. access control by workspace or workspace directory - the ability to give certain users or groups access to certain workspaces or directories. Ideally, access control can be by done by bug id.

Vesta's access controls are essentially UNIX file permissions. Through the repository's filesystem interface, you can control who can read and write (commit new versions) at a variety of granularities with chown, chgrp, and chmod.

4. graphical resolve of conflicts - a graphical three-way diff is the only way to resolve complex conflicts

Vesta provides no direct help here, but again, because of the filesystem interface to the repository, it's easy to apply standalone diff/merge/conflict resolution tools.

5. The ability to move files and directories and maintain file history and label integrity from the client. CVS requires the whole workspace to be locked so that moves can be performed on the server side and does not maintain label integrity.

Vesta's unit of version control is a directory. Between versions, files and subdirectories can be added, removed, renamed, etc.

6. web viewer and graphical difference viewer - the ability to browse via the web change set lists to see what files changed and what the actual differences were.

Not built-in, but already implemented on top.

7. the ability to integrate workspaces across projects - the ability to arbitrarily merge/integrate any source code from any project to any other project.

Vesta includes sophisticated cross-site features, including replication and remote checkout/checkin. It's been successfully applied before by a team spread across the US east and west coasts with hundreds of megabytes of sources.

8. powerful labeling features (parallel development and prior version support).

9. rollback or undo multiple changes - this is great way to recover from a developer commit disaster.

Vesta really shines in these areas. Vesta is also a build tool, and every build neccessarily includes a complete specification of the set of immutable versions it uses. Builds are also themselves immutably versioned. This makes it easy to determine which source componenets have changed between two versions of a build. Also, since it's as easy to select any historical version as it is the latest one, rolling back changes is trivial.

10. multi platform support - must run on all platforms.

We're still working on it (at the moment just Linux and Tru64 work), but hey, it's free software, and we'd love to have more developers/porters.

11. command line and graphical interface. Command line for scripts and graphical interface for those who can't work without it.

At this point there's a command-line interface and some rudimentary support for repository operations in the web interface. Again, it's free software, and we'd love to have somebody contribute more layered tools.

12. push and pull notifications - built in support for e-mail and news group notification of changes in the workspace.

Nothing built-in yet, but we've been talking about doing it, and it may happen soon.

There's a short summary of Vesta's excellent capabilities on it's web site (which includes several points not mentioned here), that I would recommend anybody interested in better version control/configuration management check out.

The best thing I've ever used, hands down, is CMVC at IBM. It does 2 things which I think are critical: it integrates with the bug tracking system and it easily supports multiple releases concurrently (as in to check code in you need a "bug" that is accepted and that bug can be associated with multiple releases and can't be closed until you roll the fixes in to all the associated releases)

I've used CVS and Bugzilla for about 3 to 4 years now (bugzilla less, maybe 2.5 years) and CVS is great when you use it right and you do what it does. It seems like about half of the developers out there don't want to do that initially though. I think it starts to get very complex when you're supporting multiple releases (very common in a business, less so in opensource) also because you can make changes check code in and it will pretty much do it or it gives you some crazy error message that most people don't understand. Really CVS solves the file aspect of the problem and that's about it. It also has some implementation bugs, it needs a temporary space the size of the repository; suppose you build a release binary that's 100MB (not at all uncommon) and check it in because you release it and you've got 500MB of source code; after 3 or 4 releases you need a GB of space to do just about anything with the tree. Say you're shipping a CD image, you know with a JDK and a bunch of docs and stuff, release 3 betas and a release and you're possibly in the 2 to 3 GB range. Twice in business settings we've had to do major work on the CVS repository because our hardware was no longer large enough to support it. These are more extreme uses but they are common in a business that is trying to implement some good software engineering practices, much easier to get away in open source.

CVS isn't the most condusive to being used in a business setting where you want to have *Everything* in a tree. It simply starts to get slow and hard to use when the trees get big. Also the best way to use it is in the clearcase mode where everybody is doing everything on a branch and just the nomenclature of that sounds bad to most engineers in business, they don't like to branch and merge. Also, it has been my experience that until the team size get's to be in the 20s or so and the project is simply too big, every engineer should do a full build at least once a day, the whole branching parts of it methodoloy seems to encourage spot builds; no real reason it just seems that way from experience, doing a full checkout seems to take too long for some people or something. Also, simply doing updates isn't the best idea either because it seems like CVS becomes confused on some client platforms (**cough** windows) and after doing that for a week or so the sandbox isn't exactly like tip.

From what I've read, it sounds like subversion starts to fix the file level problems CVS has. That's huge. The next step is to couple the issue/bug tracking system to the actual file level version control system.

Although your problem seems to be a lack of understanding (and taking advantage of) CVS, I think vesta is an awesome system. I'm not sure if you have checked out vesta yet or not, but here is a link. Here is a comparison between vesta and other popular revision control systems. Vesta was developed at DEC/Compaq, is over 10 years old, and was just released under the LGPL. Check it out.

Although your problem seems to be a lack of understanding (and taking advantage of) CVS, I think vesta is an awesome system. I'm not sure if you have checked out vesta yet or not, but here is a link. Here is a comparison between vesta and other popular revision control systems. Vesta was developed at DEC/Compaq, is over 10 years old, and was just released under the LGPL. Check it out.

That's not the way you would use it for collaboration. The NFS interface is not intended for wide-area access, only for clients within an installation (which can be as small as one system).

The right way to use it is for each contributor to run their own Vesta repository and use Vesta's replicator to keep up to date with other repositories (such as a central master). Vesta's checkout tool automatically contacts the master repository, even if it's remote, and its checkin tool replicates the checked-in version back to the master repository.

We already have several users who work this way, one even running their Vesta repository at the other end of a 56k dialup line.

(BTW, I'm the current maintainer, the one who did much of the work of getting it ported to Linux and released.)

That's not the way you would use it for collaboration. The NFS interface is not intended for wide-area access, only for clients within an installation (which can be as small as one system).

The right way to use it is for each contributor to run their own Vesta repository and use Vesta's replicator to keep up to date with other repositories (such as a central master). Vesta's checkout tool automatically contacts the master repository, even if it's remote, and its checkin tool replicates the checked-in version back to the master repository.

We already have several users who work this way, one even running their Vesta repository at the other end of a 56k dialup line.

(BTW, I'm the current maintainer, the one who did much of the work of getting it ported to Linux and released.)

That's not the way you would use it for collaboration. The NFS interface is not intended for wide-area access, only for clients within an installation (which can be as small as one system).

The right way to use it is for each contributor to run their own Vesta repository and use Vesta's replicator to keep up to date with other repositories (such as a central master). Vesta's checkout tool automatically contacts the master repository, even if it's remote, and its checkin tool replicates the checked-in version back to the master repository.

We already have several users who work this way, one even running their Vesta repository at the other end of a 56k dialup line.

(BTW, I'm the current maintainer, the one who did much of the work of getting it ported to Linux and released.)

1. Where are the sources for Vesta? How do I get a copy of the source?
[snip]
Of course it would be possible to make a .tar file of the sources available, but we don't see a lot of point in doing that. We feel that making source available for replication to any Vesta repository is sufficient, both for people who want to build modified versions of Vesta and to satisfy the requirements of Vesta's license (LGPL).

They're not going to get much traction in the linux community that way. If you can only get and build the source by using a built binary of their tool you installed from somewhere else, then how can it be trusted to be showing you the actual source, and not some decoy source hiding bugs or malware?

I find it interesting that in their Assessment of Various SCM Systems there is no mention of BitKeeper, Arch, or Subversion, all of which have been brought up here in the past.

Does anyone know how they compare? It seems to me as though this space is becoming increasingly crowded. Choice is a good thing, I just fear that it might be at the cost of being able to easily communicate code between developers.

No way, 21st century revision control: Vesta. (OK, so it hasn't made it out of Compaq's research division yet, but they're working on getting it released.)