Sometimes when people first look at Vesta they have some misconceptions about it, or just don't seem to understand what's so special. This page has some answers to some first reactions we've heard from users.
- Full copy of all revisions hanging around? That's no better than "cp -pr current_dir new_dir"!
- Vesta's a lot better than just copying around directories in several ways:
The Vesta repository uses copy on write: no copies are made unless you actually edit a file. If your package contains 100 files and you only change 2 of them, the new version only takes up additional space for the two files you changed.
Because the repository is its own filesystem, copy on write saves time on checkout and checkin operations. No copies are made when you checkout. Only when you make changes to a file will a copy be made.
- The repository also collapses redundant copies by checking the contents of each new file you create. If you happen to edit a source file back into a state identical to a file that the repository already stores, no new space will be used for it.
- The repository of course enforces strict rules about the versions you create. Once created, a version is immutable.
It's worth noting that Vesta is not the only system to take the approach of keeping full copies of all versions (though it may have been the first to do so). monotone and git both also keep full copies. This design decision is based on the fact that disk keeps getting cheaper and yet programmers don't typre any faster. Trading off the user's time to save a little disk makes much less sense today than it did decades ago when people first developed older revision control systems which use a delta encoding.
- Doesn't it take a lot of bandwidth to move around full copies?
- Vesta's replication system has several efficiencies:
- The repository knows which files have changed between different versions and only transmits those not already present at the destination.
- When files are transmitted, they're sent compressed.
- The Vesta build tool isn't as simple as Make.
Right, it's significantly better than make. Make doesn't scale well to large projects and has a host of other problems. Don't take our word for it though. The Vesta builder is specifically designed to addres many of the drawbacks of make.
- I still don't see what Vesta's killer feature is.
- Vesta's truly unique features lie in its build system.
- It has completely automatic dependency detection which works with any compiler or other tool. The user never specifies dependencies, and therefore can never get them wrong. It records dependencies which other systems miss, such as dependencies on the versions of the tools you use and dependencies on the non-existence of files.
Builds operate in a completely encapsulated environment which is isolated from the normal filesystem. This means that you can change which version of tools your build uses independently of the host operating system, and your build can't be affected by files not under revision control. One example of this is the fact that with a sinlge x86 Linux machine running Vesta, you can build for multiple different target distributions (e.g RedHat 7, Debian sarge, etc.).
Every time you build, you're using (and often creating) a unique build configuration. This can be used to tell exactly what version of every file (source code, tools, libraries, configuration) went into your build.
Builds are precisely repeatable. Because Vesta build configurations completely specify the exact version of all their inputs (and all their inputs are under revision control), you can always repeat exactly what you've done before. Because of the way replication works, this even holds up at remote locations, so you can be confident that everyone will get the sam results whether they're in the same building or on another continent.
Build results are stored in a shared cache.
Suppose Alice checks in a change to foo.c and the Bob starts using her new version. His build can get a cache hit on the compilation of the new version which Alice did before she checked in her changes. For large teams this can add up to significant time savings.
- This same feature means that you don't need to manage inidividual "build areas". Just decide on a policy of how often you want to purge old results and what should be kept when you do so. This means users spend less time doing busy work and more time in productive development.
- It's under-documented.
- Start with these:
The Vesta Approach to Software Configuration Management is a short introductory paper which gives an overview of the whole system.
The CodeCon 2004 presentation is another overview.
The tutorial and command summary will get you started with the day-to-day usage of the system.
Read the man pages, many of which have diagrams illustrating how they work
The book-length research report describes the design and implementation of the whole system. (An updated version of this is soon going to be published by Springer-Verlag.)
The build language spec describes the entire syntax and semantics in eaxcting detail.
If you want to start writing your own code using the Vesta APIs, read the dissection of the checkout tool.
- I just want version control and don't need a build system.
- Vesta works just fine in this situation too.
