Core statement on version control systems

[Alan Barrett <apb%netbsd.org@localhost>]

The NetBSD core group has been asked to make a statement on 
version control systems.

There is a strong case for switching from CVS to a modern 
distributed version control system (DVCS).  However, the 
proponents of particular DVCS systems have not presented a 
coherent plan that can be used to implement a transition from the 
current system to a new system.

In the opinion of the core group, the NetBSD project should switch 
from CVS to a DVCS system as soon as a suitable transition plan is 
presented and approved.

Some of the things that we would like to be addressed in a 
transition plan are:

* How well the proposed system satisfies the requirements and
  desires of the community, in terms of features, ease of use,
  performance, and other considerations that have been mentioned
  in the tech-repository mailing list.  It would be useful to
  have a matrix similar to the one produced by FreeBSD, available
  at <https://wiki.freebsd.org/VersionControl>.

* Performance implications of the desired VCS system, especially
  for hosts with low or moderate amounts of memory.

  Whether low performance hosts:

    - will be able to use the new system fully; or
    - will be able to use a degraded mode that will allow at
      least HEAD and branch checkouts and commits (but perhaps
      without the ability to create new branches or to merge); or
    - will be able to use a front-end or mirror that provides
      CVS-like capabilities and performance; or
    - will not be able to use revision control at all.

  Note that a checkout of the NetBSD "src" tree has nearly 150000
  files in more than 15000 subdirectories (not including "CVS"
  subdirectories, or obsolete files or directories), and the
  "src" CVS repository has more than 300000 files in more than
  38000 directories (including "Attic" subdirectories).  Almost
  all existing DVCS systems exhibit performance problems on a
  tree of this size, unless the host has ample memory.

* Whether it will be possible to run the existing CVS system
  in parallel with the new version control system during a
  transition period, and if so, how commits made to one system
  will be mirrored to the other.

* Whether one-way or bidirectional near-real-time conversion to
  other VCS systems will be possible on an ongoing basis, and
  if so, to which systems (other than the system chosen as the
  master), and how it will be configured.

* A matrix of all the supporting tools and code that currently
  assumes CVS, with plans and actions for the conversion of each
  item to the new VCS.

* How the NetBSD project's official servers should be set up,
  taking into account the needs of developers with write access,
  read-only access for the public to mirror the repository,
  read-only access for the public to check out the tree (if
  that is different from mirroring the repository), backups,
  redundancy, audit trail, email for commit messages, and any
  other issues identified with the assistance of NetBSD admins.

* How tools will be incorporated into the src tree, or
  bootstrapped from pkgsrc.

* How developers and non-developers will interact with the
  system, including workflow options for official release or
  feature branches, and for personal public or private branches
  (by both developers with write access, and non-developers).

* New standards for log messages that refer to earlier commits,
  to avoid tying us to any particular VCS in the future.
  (Roughly, what to say in log messages instead of "revision
  <number>" or "commit <hash>" or "the previous commit".)

* How the existing repository will be converted.  The following
  items would be nice to have (in decreasing order of importance):

    - how CVS vendor branches will be handled, including
      cases where the same vendor tag has been used for
      logically-distinct branches (as is common in pkgsrc).

    - how (if at all) historical log messages will be edited
      during the conversion (for example, to adjust the
      character set, to convert user names to email addresses,
      or to fix up references to CVS numeric revision numbers,
      to make them use the newly defined standards);

    - how (if at all) historical repository moves and copies
      will be identified and fixed up during the conversion;

    - whether pre-CVS history (such as the older SCCS history)
      can also be included, either at the time of conversion, or
      later;

    - whether information removed as a result of the USL v. BSDI
      lawsuit could ever be reinstated, if legal issues were
      resolved in the future.

* Considerations to avoid lock-in to a particular version
  control system, but to allow for a future change to yet
  another system.  (For example, we could choose a VCS system
  with a widely supported import and export format, and restrict
  our workflow to features that are supported by many VCS
  systems, and avoid the use of features that are unique to the
  chosen system; however, the set of widely-supported features
  should be identified.)

* An estimated time-line of the conversion, together with a list
  of people responsible for it and their respective tasks.

-- Alan Barrett, on behalf or the NetBSD core group