Some of Cascade’s unique features include:
Cloning a Prebuilt Tree
You can instantaneously “clone” a Cascade tree as of any point in time, past or present. The cloned tree exactly matches the tree that the workers used to run your tasks, so if you were to run those same tasks, you’d get the same results.
In particular, you will often want to clone the “last-known-good” revision, which Cascade will select automatically for you. This is the most recent revision where all tasks have completed and passed. By cloning last-known-good, you can be confident that the tree will work, instead of having to waste time tracking down other people’s breaks. The cloned tree is also prebuilt; a special “results” tree is included in the cloned tree containing the output files of all of the tasks. By grabbing files out of this results tree and running them directly, you can start doing your own testing immediately rather than having to wait for a build.
Once a change is checkpointed, other engineers can review it or use the change as a starting point for further development. Also, checkpointing is a simple way to move changes around from one computer to another — to move your work from your work PC to your home PC, just checkpoint at work and then clone from the checkpoint at home.
You can also ask Cascade to kick off the tasks affected by the change to see whether it will break anything. Using Cascade, you can know what you will break before you commit, rather than merely hoping for the best. As always, these tasks are parallelized on the cluster, and Cascade’s automatic dependency tracking is used to automatically determine which tasks need to be run.
Once you’re ready to commit, Cascade can restrict changes to the repository to make sure they meet a minimum quality bar, according to a “commit policy.” If the commit policy isn’t satisfied, the commit is rejected.
The default commit policy is that all tasks (builds and tests) affected by the change must have completed and passed, but there’s room here for possible customization. Perhaps you want to enforce code reviews/signoffs on changes before they can be committed, for instance? Cascade could do that.
Of course, if a commit policy malfunctions and is rejecting all changes, it’s always still possible to go around Cascade and commit directly to the underlying repository.
Multiple Repositories in a Single Tree
If you are working on a large project that spans more than one repository, or if you’re working closely with external partners who have their own repositories separate from yours, Cascade File System will seamlessly stitch these multiple repositories together into a single file system — even if they are different types of repository.
No Need for Sparse Checkouts
Call them “sparse checkouts” (Subversion) or call them “clientspecs” (Perforce); the idea is the same, to check out a subset of the files in the repository to reduce the amount of disk space and network bandwidth (and, ultimately, time) required to check out a tree. Unfortunately, these other tools require you to manually specify which files you need up front. This is a labor-intensive, error-prone process. It’s easy to ask for too many or too few files, and you can spend a lot of time trying to pick exactly the right subset of files.
Cascade File System’s elegant, patent-pending architecture makes sparse checkouts unnecessary. Each CFS tree appears to contain your entire repository, so you are never missing a file you need; yet creating a tree takes just seconds regardless of how many files are in your repository, and you can have as many trees as you want (hundreds, even thousands of trees is no problem). You don’t pay the cost of downloading a file until you actually need it.
You do not lose your Cascade cache when you power down your system, nor do cache entries “expire” or “time out” after some amount of time has passed. Cascade’s caching system only kicks out old data when it needs to make space for new data.
Or, perhaps you’d like to learn more?