FreeBSD has historically kept copies of the revision control tools necessary to fetch updated versions of FreeBSD in the base system.

This is not necessarily mandatory going forward, so describe how your proposed VCS would fit in to the base.

Subversion depends on a number of third party libraries, which can include apr, apr-util, berkeley-db, and neon. Of these, the only mandatory ones are apr and apr-util. berkeley-db is used to support repositories created with the Berkeley DB backend, and neon is used to support repositories accessed over DAV.

The Subversion port currently builds and installs a dynamically linked binary.

We believe that, if the project migrates to Subversion, it would be necessary to build our own, FreeBSD specific, Subversion client. This client would be nothing more than a version of the official Subversion client, but built statically.

This ensures that the end user does not have to be concerned about upgrading one of the dependent libraries and discovering that they can no longer access the FreeBSD repository. This would be similar to the way that the libxml library has been imported as bsdxml.

The remaining question is whether or not the code is imported and built in the base system, or whether it is kept as a separate port, but installed by default at system install time. We don't believe that this choice will materially affect the outcome.

Hg is written 95% in Python and a bit of C for two modules. It works with 2.3 although 2.4 is faster. The question whether we would need to import Pyton in the core OS is better answered by the Perl debacle.

Maintaining our own version of Python is not reasonable thus an approach were everything is in ports is probably better. Maintaining our own version of Hg is not a good option either. Having important tools such as VCS in the core is a satisfying feeling but Hg is still a moving target right now.

That would make Python and Mercurial more or less mandatory tools but the size of Hg itself is not seen as a problem.