Description
The VCS should allow for disconnected work, including creating new working trees, diffing, branching, and committing (whether that's to be pushed later or just local).
It should be possible to only clone portions of the remote repository locally.
Current Implementation
We currently use CVSup to distribute the CVS ,v files to allow creating new working trees and diffing. This means relying on modula3, which limits what architectures this can be done on.
CVSup allows the user to determine which portions of the tree will be downloaded.
Branching and committing are not supported.
SVN Implementation
A Subversion working copy (i.e., what you get by running "svn checkout", and analagous to a "cvs checkout") always contains a pristine copy of the original checked out files.
This allows you to run "svn diff" without network connectivity, and see what local modifications have been made.
Subversion repositories can also be mirrored, using the svnsync(1) utility (new in SVN 1.4). This would allow you to mirror all of of the FreeBSD repository locally, and use that mirror to examine logs, and diff against previous revisions locally.
svnsync(1) only allows you to mirror the entire repository, and not subsets of it.
SVN::Mirror (and its associated command line tool, svm(1)) is a Perl module that allows you to mirror arbitrary paths from remote Subversion repositories in to a local Subversion repository, with the caveat that the local revision number will always be at least one greater than the remote revision number.
SVK Implementation
SVK builds upon SVN::Mirror, and allows you to mirror 1 or more remote Subversion repositories locally. You can then carry out all the normal Subversion commands (diff, merge, checkout, etc) against these local repositories. This includes committing changes.
Once network connectivity is restored SVK can push the locally committed changes back to the remote repository (assuming they do not generate conflicts). These changes can either be replayed one by one back to the remote repository, or can be lumped together in to one large commit that encompasses all of the commits made offline.
Because SVK works against unmodified remote Subversion repositories it does not need to be mandatory. Those committers that require disconnected operation can elect to use SVK, those that do not can use the SVN client. It's perfectly possible to mix and match the use of the SVN and SVK clients against the same remote Subversion repository with no ill effects.
Hg Implementation
An Hg clone is a full repository, and may be cloned again, its history examined, and commits made. All work except for pulling down new changes and pushing new changes upstream is disconnected from the network (same as git).
Git Implementation
A git clone is a full repository, and may be cloned again, its history examined, and commits made. All work except for pulling down new changes and pushing new changes upstream is disconnected from the network.
Monotone Implementation
Supported (also see the related page on Monotone wiki)
The only operations that use the network are those that transfer revisions: sync and its one-way cousins pull and push. All other operations, including commit and merge, are distributed and occur locally offline. Developers can continue to work offline, publishing their work and learning of the work done by others with a quick sync whenever network access is available.