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.

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
VCSRankRequired

Ability to import entire current CVS repository, including history

Yes

Partially

Yes

Partially

VCSFeatureVendorBranches
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Support tracking vendor sources (bind, gcc, ...), import/map existing branches.

Yes

Yes

Yes

Yes

VCSFeatureMerging
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Automated or mechanically assisted merging

Yes

Yes

Yes

Yes

VCSFeatureBranch
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Fast system for common operations

Unknown

Yes

Yes

Unknown

VCSFeatureACL
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

The replacement must build and operate correctly across all the server architectures that FreeBSD supports.

Yes

Yes

Yes

Yes

VCSFeatureNetworkSecure
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Network operations should be secure.

Yes

Yes

Yes

Yes

VCSFeatureAtomicCommit
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Atomic commits to get real changesets

Yes

Yes

Yes

Yes

VCSFeatureCVSExport
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Ability to keep and distribute a reference tree, knowing that it should also be exported to CVS

Yes

Yes

Yes

Unknown

VCSFeatureRename
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Ability to rename files within directories without losing history

Yes

Yes

Yes

Yes

VCSFeatureOffline
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

It must be possible to mirror the repository to remote sites.

Yes

Yes

Yes

Yes

VCSFeatureGoodRepositoryFormat
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
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
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

The VCS must provide mechanisms for the tinderbox to hook in to it.

Yes

Yes

Yes

Yes

VCSFeatureBaseSystem
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

How is the VCS going to integrate in to the base system?

Yes

No

Yes

No

VCSDatabaseRecovery
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Sometimes sh*t happens.

Yes

Partially

Yes

Yes

VCSHistoryPruning
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

We'd like to get the last three months (for example) out of a given tree.

No

Not yet

Yes

Unknown

VCSPartialTreeClones
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

We'd like to have clones of portions of the tree.

Yes

Partially

Partially

Unknown

VCSFeatureSymlinks
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

It is desirable to be able to place symlinks under version control.

Yes

Yes

Yes

Unknown

VCSFeatureSign
VCSRankRequired
VCSRankDesired
VCSRankOptional
VCSRankGratuitous

Ability to digitally sign revisions or repositories to avoid file corruption and to detect unwanted modifications.

Yes

Yes

Yes

Yes

VCSFeatureMIMEType
VCSRankRequired
VCSRankDesired
VCSRankOptional
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

Git

VersionControl (last edited 2012-02-27 07:41:59 by RoyceWilliams)