[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Core statement on version control systems
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
* 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
- 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
Main Index |
Thread Index |