Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

The Vesta Configuration Management System

Vesta is a CM system released under the LGPL by Compaq (now HP). It is designed to allow tight control of very large projects. The Vesta project describes itself:

For substantial software systems (say, 500k source lines or larger), effective software configuration management (SCM) is a serious problem. It is not generally known how to make a configuration management system that is both easy to use and general enough to handle multi-million line software projects. As a result, the world is full of easy-to-use, small-scale configuration management tools and large-scale, hard-to-use ones.

Vesta is a portable SCM system targeted at supporting development of software systems of almost any size, from fairly small (under 10,000 source lines) to very large (10,000,000 source lines).

Vesta is a mature system. It is the result of over 10 years of research and development at the Compaq/Digital Systems Research Center, and it was in production use by Compaq's Alpha microprocessor group for over two and a half years. The Alpha group had over 150 active developers at two sites thousands of miles apart, on the east and west coasts of the United States. The group used Vesta to manage builds with as much as 130 MB of source data, each producing 1.5 GB of derived data. The builds done at the eastern site in an average day produced about 10-15 GB of derived data, all managed by Vesta. Although Vesta was designed with software development in mind, the Alpha group demonstrated the system's flexibility by using it for hardware development, checking their hardware description language files into Vesta's source code control facility and building simulators and other derived objects with Vesta's builder. The members of the former Alpha group, now a part of Intel, are continuing to use Vesta today in a new microprocessor project.

I have not tried it myself, but I recently had an interesting conversation with Ian Wienand. His group decided to try it out, and I asked him how it turned out:

So how has it worked out? Did you enjoy it? What has annoyed you in Vesta?

Well, the situation was a hard deadline (OSDI), a pre-existing source tree and a whole bunch of people looking to get rid of CVS.

It never worked out for us, even with two in house champions. Classic software engineering 101 stuff; combine a new and complicated product (that may or may not be better) with people who are pretty set in their ways with their old product that basically works anyway...

If we didn't have the hard deadline, maybe people would have given it more of a chance, but after about a week of trying to use it a meeting was held and it was like "who is spending more time struggling with Vesta than actually hacking?"; hands were raised and we were back to the status quo. For such a huge paradigm shift in the view of source control, we never even gave it a chance.

But everyone always has deadlines; that's life. You have to really *want* to use Vesta to use Vesta; it's not easy to setup, run or maintain. Maybe those things could be worked out with more developers and documentation but it's a long path.

I think Vesta can be described as a little too academic; a great idea that if everyone should be using, but for some reason reality is different (c.f. Tanenbaum's recent microkernel jabs).

Vesta integrates both CM and a build system. Changing your build system and VC system at the same time is likely to be more than twice as hard as changing just one.

Yes, totally. It's monolithic in that sense; everything is bundled together.

We have been having quite good success at HP with SCons and Subversion. SCons in combination with ccache gives you very fast and reliable rebuilds, so there is no excuse for broken commits. Subversion makes sure the commits are atomic.

I think migrating to an architecture like that has a much higher probability of working because it describes the time tested UNIX philosophy of plugging together small components that do one thing well.

I wish we had of of tried something that -- thinking out loud

• ccache/distcc drops around gcc, no changing how you work
• We have ended up with our own internal build environment (in Python too) which people had to learn their way around anyway. Equivalent of changing to Scons (but Scons has the advantage of a community).
• CVS -> Subversion/Arch change is manageable.

The beauty is there if any one piece fails to catch on, you've still got the advantages of the other bits. With Vesta, it's take it or leave it.

I have a feeling Vesta started out as a strong in-house thing at Digital, where people probably got really used to it and set things up so it would work well. If you weren't born into it it might be hard to adapt...

I think also maybe it works well for, say, closed source operating system group where you 100% need the same tools chains because your code is so dependent, everyone who wants the code is a developer, you have very well defined targets and your ultimate goal is to ship a binary.

I think your traditional open source model fails on every single one of those points :)

posted Fri 28 May 2004 in /software/vc/vesta | link

Copyright (C) 1999-2007 Martin Pool.