During this season of giving, you can show your support for the NTP Project by making a donation to Network Time Foundation.

Source Code Management


The NTP Project used no source code management for many years.

Eventually, we started using CVS, and that worked well for a while.

After a while, the limitations of CVS started driving Harlan crazy, and since he is the driver of the beast, he looked for a replacement. After about 2 more YEARS of study and looking, he chose BitKeeper and has been very happy with it ever since.

In early 2005, it was announced that BitMover would be stopping its free use license for BitKeeper. Since then, it was released as open source under the Apache 2.0 license.

While we were looking to continue on using the commercial version of BitKeeper, people asked about evaluating a replacement for BitKeeper.


  • The SCM must be invisible to Dave Mills
  • its use must not require any signature from anybody at UDel for its use there
  • it must support file and directory renames
  • it must support tracking of file/directory permission attribute changes
  • it should support checkins for work-in-progress
  • it must support the functionality we have with the existing triggers, described in the BitKeeper/triggers/trigger.cfg file of any ntp-dev or ntp-stable repo, which execute the following scripts:
    • BitKeeper/triggers/notify (used for debugging)
    • BitKeeper/triggers/paranoid (used for security)
    • BitKeeper/triggers/commitlogs (commit log email)
    • BitKeeper/triggers/2mirrors (updates repository mirrors)
    • BitKeeper/triggers/send (changeset email)
  • it must easily support ntp-stable and ntp-dev repositories, and pulling changesets from ntp-stable to ntp-dev, and should support pulling changesets from ntp-dev to ntp-stable
  • it must support integration areas
  • it must be robust, reliable, and easy to use
  • it must not be a pig
  • it must have useful merge support
  • it must have useful branch/LOD support
  • it must have an easy/useful way to find when changes were made
  • it must have a useful web interface

There are probably more, but this is the list off the top of my head. Oh, please also see MaintainerIssues#How_to_work_on_a_bug for how I like to handle dealing with patches and things.

SCM Matrix

What URL Architecture license Notes
bitkeeper https://www.bitkeeper.org/ distributed Apache 2.0 Harlan likes this best
darcs http://darcs.net/ distributed GPL Seems "young" to Harlan, seems to be dying to Ryan
SVN https://subversion.apache.org/ centralized BSD-style most mature and widely used SCM, great tools, cross-platform, merge tracking a weakness
perforce https://www.perforce.com centralized commercial Do we need a UDel signature for its use at UDel?
gnu-arch https://www.gnuarch.org distributed GPL Funky file names? Windows?, seems to be dying to Ryan
git https://www.git-scm.org distributed GPLv2 super-fast, big community, GUI tools and Windows ports getting better
Mercurial https://www.selenic.com/mercurial/wiki/ distributed GPLv2 stable, widely used, good GUI tools and cross-platform support
Bazaar https://bazaar-vcs.org/ distributed GPLv2 Windows issues (no line ending conversions)

Comparisons and References


If you would prefer to add your comment below instead of editing the table above, please do so. You can also email your comments to webmaster@ntp.org .

  • One of the major gripes with P4 amoungst the FreeBSD userbase is the utter lack of decent support for anonymous r/o checkouts. In this respect, switching to perforce would make "public" access to ntp's development source much worse than it is now. -- WikiGuest - 06 Dec 2005 15:27:22

  • I updated the SCM table above. I think if you look at the current post-CVS SCM landscape, there are really only 4 open source choices: SVN, git, Mercurial, and Bazaar. Using an "obscure" SCM like SVK or BitKeeper will not encourage participation. The fact that the project uses non-free BitKeeper could prevent a lot of contributors; I have never inspected the history or tried to contribute because of that very fact. The "free" Bitkeeper is useless, I don't have a BitKeeper license, and I don't want to learn yet another SCM. My suggestion would be to use Mercurial, as it is almost as easy to use as Bazaar, but has better support for Windows and better GUI tools. -- RyanMalayter - 13 Apr 2009

  • Ryan, thanks for updating the table and I appreciate the input. What is stopping you from creating a diff patch and submitting that? I'm not convinced we'd see a noticeable uptick in contributors if we switched away from bk, and even if we did:
    • it would be a huge amount of work for me (remember, we have spent a Lot of effort on the release engineering side of things, which is a heavy user of the SCM).
    • there is a chance there would be at least some problems along the way and we'd have to either try a different SCM or abort the effort and continue with bk.
    • I would also bet that if we chose 'A' then there would be a vocal group that said "Why did you pick 'A' when 'B' is better?"
    • I sometimes have to use other SCMs - they are all pretty similar and all have their own quirks. I don't buy the argument that learning bk is too much effort. And having used both svn and git, I still like bk better than either.
    • bk remains my favorite SCM tool and I am one of the heaviest users of this tool for NTP.
    • the BitMover folks have been Very Good to us, for a very long time. They continue to be Very Good to us. We benefit from using bk and I am happy (even eager) to spread this news around - I hope BitMover befits from our (published) use of bk and from my telling folks how happy I am with bk. I am not fickle; I choose my relationships carefully and consciously. I'm not about to flush my/NTP's relationship with BitMover just because an open-source alternative is almost as good (or even "as good", and I haven't seen this yet).
      -- HarlanStenn - 06 Mar 2011


-- HarlanStenn - 09 May 2005
Topic revision: r15 - 04 Oct 2022, TodaysTest
Copyright © by the contributing authors.Use of this website indicates your agreement with, and acceptance of, the PrivacyPolicy, the WikiDisclaimer, and the PrivateWebPolicy.