• MarketingStrategy
• ThingsOnlyVestaCanDo

Things Only Vesta Can Do

Up in MarketingStrategy, Adam suggested "10 tutorials: 10 things that only vesta can do". This page has some random ideas.

Keep Editing While Building

Vesta builds only use immutable (ie, read-only) versions of source files. When you're actively working on something, this means that an immutable snapshot gets taken when you build. (See the diagram in the vadvance(1) man page.)

If your build process is long-running, you can start working on the next edit while it's compiling your last one. The build will be using an immutable snapshot, not your editable copy. In other words editing cannot affect on-going builds.

Share Work-in-progress Precisely

If you're in the middle of working on a change, but you need to share your work with another user, just point them at one of your immutable (ie, read-only) snapshots. They can use that to build or examine your changes while you keep editing. Because it's an immutable snapshot, they don't need to worry about your forward progress interfering with what they're doing.

Share My Compilation Results

If I give you my new .hxx file to incorporate into your build, with CVS/make you will have to re-compile much of your source tree. With vesta, you automatically can cache-hit on all the compilations i've already done with this .hxx file.

Rebuild Only When *Really* Changed

Vesta fingerprints a file's contents and uses a changed fingerprint to determine a change in a file -- not dates.

Thus, If i wind up changing a file's date (touch it, copy it, or edit it--then un-edit and save, etc), but dont change it, vesta sees that it's the same file and does not rebuild. 'make' would see it as updated. If it is a header file (.h .hxx) this might trigger many re-compiles.

And, if i build my program (build 0), then change a file and build (build 1), then change that file back to exactly what it was in build 0 (ie, i changed my mind) and build again (build 2), 'make' will rebuild everything that depends on the file, whereas vesta will cache-hit on the results from build 0 and if nothing else changed, will finish (almost) instantly.

Checking in/out doesnt cause rebuild

The act of checking-out a package creates a new snapshot of that package in a snapshot dir (called a session dir), but doesnt change any file contents. Assuming that the checked-in files have already been built successfully (which is typical), if you rebuild immediately after check-out, before making any new changes to file contents, vesta is smart enough to see that no files changed and you will cache hit and your build will finish almost immediately.

Similarly, the act of checking-in is one of moving files from the snapshot into a new directory named for the new version. Assuming you built right before checking-in, and haven't changed any sources since then (which is typical), if you build the version you just checked-in, vesta is smart enough to see that no file contents actually changed and you will cache hit and your build will finish almost immediately.

"Perfect" version control

Vesta may not quite exhibit PerfectVersionControl, but it gets much closer than any other known SCM or Build Systems.

Recording a 2-Step Change

Say you're editing a file, fixing a bug, and at the same time you decide to change a variable name throughout the file. Looking at diffs of this change, it would be hard to extract the significant bug-fix change, from the trivial variable name change.

To make this easier with CVS, you could change only the variable name, check-in, then check-out again and make the bug-fix change. While this would work to isolate the 2 changes, your variable name change is now visible to everybody and may trigger reubuilds that really aren't necessary.

Another CVS option is you could create a branch, just to isolate these 2 changes, but that's expensive.

With vesta's work-area snapshotting, you can make the variable change, do a vadvance and store that version forever. It is in your permanent, read-only snapshot dir corresponding to your work-area, for easy diffing, but others will only see it if they explicitly ask to use that version (which they typically would not).

Rebuilding when only the version of the compiler changed

If you're using make, and you upgrade your compiler, make does not automatically detect this change and rebuild. Most people just make clean and rebuild everything. That's because it can be hard to determine just what needs to recompile -- which would be a manual process.

Vesta does detect just exactly what needs to recompile based on a new compiler version, since the compiler is just another input to the build. In fact, changing the version of any tool in your build will trigger a re-build of everything that depends on that tool, and only what depends on that tool. [How do other build systems handle this?]

Rebuilding when only the makefile changed

If you're using make, and you change only the makefile, make may or may not rebuild. If you've added a new dependency which has a newer date, then you get a rebuild. But if you add a new dependency with an older date, or remove a dependency (ie include file), make does not detect this change and rebuild. Most people delete the build results files (eg, obj file, exe) manually, or just make clean and rebuild everything, to work around this.

Vesta considers the build.ves file (makefile equivalent) just another source input, and does dependency detection on it the same way it does on every other source file, so it determines exactly what needs to recompile based on the makefile change. [How do other build systems handle this?]