Description
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.
Current Implementation
SVN Implementation
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 Implementation
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.
Git Implementation
Git is written primarily in C with a few perl, python, and shell scripts. These perl and shell scripts are being quickly replaced with a Summer of Code project dedicated to replacing the rest of them such that Git will be entirely in C. As far as library dependencies libiconv is required and libexpat and curl are required for http push and pull. At this point it seems (almost) all perl or python based builtins have been removed and all of the shell script ones work well with /bin/sh (and are slowly being rewritten anyway). It's also possible to build git without libiconv. This means that a build of git without additional dependencies could easily be merged into base. That might not be in our best interest though since git development is rapid and some of the functionality that requires dependencies may be immediately desirable.
Monotone Implementation
Monotone is implemented in C++ and currently requires devel/boost, converters/libiconv and devel/gettext libraries to run. The use of (the rather big) Boost library may be the main reason it couldn't be included in the base system.