This is an old revision of the document!
Background
The FreeBSD Project is currently actively discussing its use of revision control with an eye towards a potential change in the future. FreeBSD uses a mixture of [“CVS”] and [“Perforce”] for managing the various source trees and projects; CVS (extended with cvsup) is the “authoritative” revision control system, and contains four complete and independent repositories (src, ports, projects, doc), but its limitations regarding heavily branched independent development are significant. Perforce provides a sandbox development environment in which projects of varying sizes (from TrustedBSD/sun4v/SMPng/zfs/gjournal/… down to man page tweak trees) with the advantages of history-aware merging and lightweight branching. A change in version control system would be a significant event for the project, as FreeBSD really entirely revolves around revision control internally and in its interface to its consumers. However, for the first time, it appears that there may be a number of sufficiently mature “next generation” revision control systems that could replace the current cvs/cvsup/perforce combination with a unified solution that better supported the requirements of the project.
Obviously, the set of trade-offs is extremely complicated. The cost in time, retraining, migration, not to mention the risk, is enormous. This page and subsequent pages attempt to summarise what we know so far, and in particular, our on-going evaluation of the project's requirements and the ability of various revision control systems to meet them. Some turn out to be more tricky than others: for example, the requirement for obliteration (removal of code and its entire history from the tree) turns out to be contrary to the designs or implementations of many newer systems. This is “made to work” with CVS/cvsup, and while not as successful as we like, sets a minimum bar quality of implementation for this and other features. We have several teams up and running exploring and evaluating different options, with the intent that at some date in the moderately near future, the results of these explorations be presented to the Project to determine whether we're at a point if and where a transition should be made. “The set of available systems isn't yet ready to replace our status quo” is definitely an acceptable answer, as paying the cost of conversion without getting sufficient benefit would clearly be a mistake. These explorations necessarily involve experimental import, deployment, scalability testing, etc. Also, members of the Project have already been in touch with authors of several of the revision control systems to discuss issues already identified.
What we are hoping to see here is not text of the form 'I really hate/love the one I am using', but what features about the one you are using you consider acceptable and which you consider unacceptable, and why.
Existing Version Control Systems
Here is a list of “major” VCS available in the Open Source world. This is not by far complete but tries to list the ones that could be good candidates for the FreeBSD project. Systems marked with a “(*)” are ones that appear to have teams actively working on evaluating them for FreeBSD use.
- Subversion aka [“SVN”] (http://www.subversion.org/) (*)
- SVK which brings history-aware merging and distributed features to [“SVN”] (*)
- Mercurial aka [“Hg”] (http://www.selenic.com/mercurial/) (*)
- Bazaar VCS aka bzr (http://bazaar-vcs.org/)
- Git and cogito (http://www.kernel.org/pub/software/scm/git/ and http://www.kernel.org/pub/software/scm/cogito/) (*)
- [“Monotone”] aka MTN (http://venge.net/monotone/) (*)
Requirements for a FreeBSD Version Control System
Here is a speculative list of desired features/requirements, vaguely in order of importance (see [“VCSFeature”] for information about laying out these pages, or use [“VCSFeatureTemplate”]. The first dozen or so are strictly required for any replacement, as they are features already provided (and heavily depended on) in our current blend. Towards the end we start to hit desired/optional features. Implicit to all of these is a certain assumption of minimum functionality provided by existing systems, such as the keeping of revisions, etc.
Note: If you update this table, do not forget to update the different VCSFeature* subpages as well!
| Background | Supported? | ||||||
|---|---|---|---|---|---|---|---|
| Feature | Description | SVN | HG | GIT | MTN | ||
| [“VCSFeatureCVSImport”]BR[“VCSRankRequired”] | Ability to import entire current CVS repository, including history | Yes | Partially | Yes | Partially | ||
| [“VCSFeatureVendorBranches”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Support tracking vendor sources (bind, gcc, …), import/map existing branches. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureMerging”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Automated or mechanically assisted merging | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureBranch”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Easy & cheap branches (and history-aware merging) and tags to enable parallel lines of development (that is essential for projects like SMPng which have a very big impact on many source files) | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureObliterate”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Obliterate functionality, to remove complete content and history from the repository in the event of import errors, policy decisions to remove content, etc | Partially | Partially | Yes | No | ||
| [“VCSFeatureFast”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Fast system for common operations | Unknown | Yes | Yes | Unknown | ||
| [“VCSFeatureACL”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Access control: the ability to constrain developers to operating in specific areas of the tree, implement branch-based policy restrictions, as well as to enforce policy such as tagging of commits for developers working outside their normal areas. Implementing these via hooks would not be a regression from what we currently do in CVS. | Yes | Yes | Yes | Partially | ||
| [“VCSFeaturePortable”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | The replacement must build and operate correctly across all the server architectures that FreeBSD supports. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureNetworkSecure”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Network operations should be secure. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureAtomicCommit”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Atomic commits to get real changesets | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureCVSExport”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Ability to keep and distribute a reference tree, knowing that it should also be exported to CVS | Yes | Yes | Yes | Unknown | ||
| [“VCSFeatureRename”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Ability to rename files within directories without losing history | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureOffline”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Ability to work offline – like on a plane – without requiring too much work: not only being able to list differences but also to commit | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureDollarFreeBSD”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Provide a mechanism to allow end users to easily see the version of the source code they were built from. Currently implemented with $FreeBSD$ tags in the repo. | Patches | Yes | Yes | Partially | ||
| [“VCSFeatureLogTemplates”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | The repo as a whole must support a log message template. Support for different templates for different paths would be useful. | Patches | Yes | Yes | No | ||
| [“VCSFeatureLogReview”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Log messages should be reviewed to ensure they contain the correct information. For example, “Approved by: re” during code freezes/slushes | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureMirroring”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | It must be possible to mirror the repository to remote sites. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureGoodRepositoryFormat”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | The VCS's repository should be stable, relatively safe during crashes, and small enough for developers to keep copies. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureWebInterface”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | There should be a way to browse the repository from a web browser, review changes, and so on. viewcvs.cgi + CVS export is unlikely to be a long term solution. | Yes | Yes | Yes | Unknown | ||
| [“VCSFeatureCommitMail”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | E-mail messages to one or more addresses should be generated when a change is committed. Format of e-mail may change (e.g., doc committer committing to src tree) | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureTinderbox”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | The VCS must provide mechanisms for the tinderbox to hook in to it. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureBaseSystem”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | How is the VCS going to integrate in to the base system? | Yes | No | Yes | No | ||
| [“VCSDatabaseRecovery”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Sometimes sh*t happens. | Yes | Partially | Yes | Yes | ||
| [“VCSDistributedSystems”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | What distributed really means to our workflow. | Unknown | Unknown | Unknown | Unknown | ||
| [“VCSHistoryPruning”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | We'd like to get the last three months (for example) out of a given tree. | No | Not yet | Yes | Unknown | ||
| [“VCSPartialTreeClones”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | We'd like to have clones of portions of the tree. | Yes | Partially | Partially | Unknown | ||
| [“VCSFeatureSymlinks”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | It is desirable to be able to place symlinks under version control. | Yes | Yes | Yes | Unknown | ||
| [“VCSFeatureSign”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | Ability to digitally sign revisions or repositories to avoid file corruption and to detect unwanted modifications. | Yes | Yes | Yes | Yes | ||
| [“VCSFeatureMIMEType”]BR[“VCSRankRequired”]BR[“VCSRankDesired”]BR[“VCSRankOptional”]BR[“VCSRankGratuitous”] | It is desirable to be able to indicate a file's MIME type, in the case of binary files in the repository. | Yes | No | Yes | Yes | ||
Additional per-VCS notes
Use this section to add links to any extra notes about each VCS that you feel may be useful.
Mercurial
Symlink support has been implemented and released as part of recent development builds of Mercurial. The plan is to have full support by the time 1.0 is released. Partial tree support and obliterrate have been requested and the developers are aware of these needs. Mercurial has experimental extensions to manage externally referenced trees (“overlays”) and forest of trees (“forest”). There is now an extension to do some cherrypicking (“transplant”).
Subversion
- [“SVN Repo Layout”]: A proposed repository layout if FreeBSD moves to Subversion.
- [“SVN Merging”]: A walkthrough of merging changes with Subversion and svnmerge.py.
- [“VCSWhy”]: Peter's view on why we need a new VCS and why Subversion should be our prime target.
Git
- GitConversion: Why git is interesting to us, and particular issues for it.