vi ;;Quote: in Vesta, every system build occurs from scratch; all files and procedures are immutable and immortal; builds are repeatable, incremental, and consistent

8 ;;Quote: a build consists of actions applied to sources and derived files (deriveds)

8+;;Quote: a build is consistent if every derived file is up-to-date relative to its source files

17 ;;Quote: every Vesta process has a current or working directory for relative paths, and a root directory for absolute paths; defined when the process is forked

22 ;;Quote: Vesta implements immutable and mutable directories; an immutable directory holds versioned, immutable source files

22+;;Quote: a Vesta repository stores every version of every file as immutable sources in a hierarchical name space; the path includes a version name or number

23 ;;Quote: a Vesta package is a collection of related files and a system model for building the package

23+;;Quote: all versions of a Vesta package are subdirectories of the package directory; individual files are not versioned

24 ;;Quote: checking out a Vesta package reserves a version name and makes a working copy; builds use immutable snapshots created by vadvance; checking in a package binds the version name to the last snapshot and deletes the working copy

26 ;;Quote: Vesta builds execute in an encapsulated environment, including the file system; every file system referent is recorded as a dependency; all file accesses use temporary build directories

36 ;;Quote: a Vesta ghost is a deleted file; a stub is a placeholder or reserved name; builds do not use ghosts or stubs

46 ;;Quote: all Vesta repositories share the same namespace; /vesta followed by an Internet domain name

46+;;Quote: Vesta subtrees may be replicated; the agreement invariant says that no name is bound to different values in different repositories

47 ;;Quote: every Vesta object has at most one master copy; only a master directory can append new names; non-master directories use replication

47 ;;Quote: a non-master stub is a placehoder for data in another repository; master appendable directories use non-master stubs for named objects held elsewhere

52 ;;Quote: mutable attributes defined for Vesta objects in mutable directories; not visible during builds; e.g., whether a directory is a check-out session or package, who created a package, what is the previous version

55 ;;Quote: Vesta access control by attributes assigned to an object or parent directory; similar to Unix; e.g., user@realm, ^group@realm, #owner, #group, #mastership-to

60 ;;Quote: Vesta defines builds with a functional language, SDL (system description language); dynamically typed with closures and bindings; can be hard to understand

62 ;;Quote: a build is a series of tool invocations in a controlled naming environment; each invocation has a slightly different environment or binding; defines dot as the implicit, current environment

62+;;Quote: Vesta uses closures to delay tool invocations until the resulting files are needed

64 ;;Quote: Vesta merges hierarchical bindings with the overlay and recursive overlay operators;

96 ;;Quote: cache files and build results by fingerprint; distinguish large (1+ MB) and small files

98 ;;Quote: Vesta keeps directory structure in memory with files stored as shortids

98+;;Quote: Vesta stores directories as a DAG of base pointers plus lists of changes

98+;;Quote: log and checkpoint memory-resident data using a destructive checkpoint; recover data from the checkpoint file

98 ;;Quote: no parent links for Vesta directories; allows DAG with shared subdirectories, e.g., a package version and its successor

101 ;;Quote: an NFS file handle is a 32-byte reference to a file or directory

101+;;Quote: a Vesta longid is a 32-byte encoding of a directory path by index number; gives parent directory; never reused

101+;;Quote: the NFS file handle for Vesta files in volatile directories is a shortid plus fingerprint

108 ;;Quote: most operations on a Vesta repository affect only one repository; the rest use two repositories; all operations maintain the agreement invariant

108 ;;Quote: the Vesta repository operations are create, append, replace a master stub, make a ghost, copy between appendable directories, create a non-master stub, and transfer mastership

108+;;Quote: Vesta does not require multi-site atomic transactions to maintain the agreement invariant

116 ;;Quote: the Vesta cache is indexed by the fingerprint of all dependencies at a function invocation site; secondary dependencies checked by their name and fingerprint

120 ;;Quote: dependency paths are the secondary keys for Vesta's function cache; a dependency path is a type and a path; e.g., complete value, existence, false existence

131 ;;Quote: an immutable directory and system model limits the propagation of dependencies; alternatively, a system model is a closure of its file and import clauses

135 ;;Quote: partition a primary key by the values of its common names; i.e., those names used in every cache entry

144 ;;Quote: Vesta's bridges are balanced subtrees of files; if a file changes, only one subtree is affected, reducing cache lookups

148 ;;Quote: a Vesta administrator specifies the deletion policy of the function cache weeder; e.g., keep lastest releases, latest build, and checkouts

150 ;;Quote: the Vesta weeder deletes cache entries and their derived files from the function call graph, as represented by the graph log

152 ;;Quote: concurrent weeding by cache entry leases and a hit filter; prevents deletion and forces cache misses respectively

172 ;;Quote: Vesta is faster than Make on both scratch and incremental builds; much faster if several files change; low overhead