Map
Index
Random
Help
th

QuoteRef: heydA_2006




Topic:
system builds
Topic:
file directory
Topic:
defining a process
Topic:
immutable files and data
Topic:
version control
Topic:
deployable module or assembly
Topic:
configuration management
Topic:
replicated data
Topic:
attribute-value pairs as information
Topic:
security by access rights
Topic:
binding of names to objects
Topic:
functional programming
Topic:
evaluation in an environment
Topic:
one-way hash function
Topic:
data caching
Topic:
hierarchical structures
Topic:
log-structured rollback-recovery
Topic:
dependency analysis

Reference

Heydon, A., Levin, R., Mann, T., Yu, Y., Software Configuration Management using Vesta, Springer, New York, NY, USA, 2006, SBN-10: 0-387-00229-4. Google

Quotations
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

Related Topics up

Topic: system builds (43 items)
Topic: file directory (55 items)
Topic: defining a process (23 items)
Topic: immutable files and data (59 items)
Topic: version control (34 items)
Topic: deployable module or assembly (12 items)
Topic: configuration management (25 items)
Topic: replicated data (51 items)
Topic: attribute-value pairs as information (57 items)
Topic: security by access rights (38 items)
Topic: binding of names to objects (19 items)
Topic: functional programming (45 items)
Topic: evaluation in an environment (35 items)
Topic: one-way hash function (24 items)
Topic: data caching (35 items)
Topic: hierarchical structures (46 items)
Topic: log-structured rollback-recovery (13 items)
Topic: dependency analysis (34 items)

Collected barberCB 7/07
Copyright © 2002-2008 by C. Bradford Barber. All rights reserved.
Thesa is a trademark of C. Bradford Barber.