• VersionControl

Version Control

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 (*)

• SVK which brings history-aware merging and distributed features to Subversion (*)

• Mercurial aka hg (*)

• Bazaar aka bzr

• Git (https://git-scm.com/) and Cogito (https://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!

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 obliterate 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 cherry-picking ("transplant").

Subversion

• /SubversionRepositoryLayout: 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.

• PeterWemm/SVN_WIP

Git

• GitConversion: Why git is interesting to us, and particular issues for it.

CategoryHistorical