Re: Why I'm working on a NetBSD conversion

["Eric S. Raymond" <esr%thyrsus.com@localhost>]

Alan Barrett <apb%cequrux.com@localhost>:
> >Could you explain what you mean by "checkout" here?
> 
> He means that, after one installs NetBSD from distribution media,
> the resulting system should include the tools needed to check out a
> copy of the NetBSD source code from the central repository (or from
> a local or public mirror or fork).  I'd add that merely checking out
> is not enough; we'd probably want to be able to perform all the
> other common actions too (log, diff, branch, merge, commit, etc.).

Thank you for the explanation.

> This has implications for the licence, size, and dependencies, of
> the version control system.  git depends on perl, and hg depends on
> python, but neither perl nor python are part of the NetBSD base
> system.  Perhaps there is a useful subset of git that does not
> depend on perl, but it seems unlikely that there would be a useful
> subset of hg that does not depend on python.

"Core" git is to some extent a question of definition.  But if you
mean the tools required to do clones, pulls, commits, pushes, and
the other operations you mentioned, those no longer depend on Perl. It
still is used for a couple of auxiliary tools.

One, amusingly, is the CVS importer, which depends on a horrible Perl
wrapper surrounding a badly broken and no longer maintained C
program. (I was the C program's maintainer for a while, until I EOLed
it with extreme prejudice; cvs-fast-export is vastly better.)

I'd say the most serious scripting-language dependency git now has 
in day-to-day use is on Tcl for gitk.

It is indeed unlikely (I would actually say "impossible") that any
useful subset of hg would allow NetBSD to remain Python-free. Why on
earth you would *want* to remain Python-free is a different question.

If checkout capability without scripting-language depenendency is
a hard requirement, your choices reduce to git and Fossil.  And
Fossil dsoesn't scale.
-- 
		<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>