Subversion for DF sources

[Csaba Henk]

On 2006-01-12, Erik Wikström <erik-wikstrom at xxxxxxxxx> wrote:
> I'd say that if there is a move then it will be to a decentralized VCS 
> and with some luck it will include an efficient checkout in the package.

Hm, I went for Mercurial and I'll never look back (the same regards to
the Linux kernel tree on my Linux box and would regard to FBSD source
tree on my FBSD box if someone would ever care to set up a Mercurial
mirror for it).

Yes, it will be never included in the base, because it's in Python
which is not feasible for the base. But honestly, is it worth to care
about? You can either:
 
 * pkg_add python, bootstrap pkgsrc, insert Corecode's unofficial
   Mercurial installation ruleset, install Mercurial;
 * bootstrap pkgsrc, compile python, insert Corecode's unofficial 
   Mercurial installation ruleset, install Mercurial;
 * pkg_add python, install Mercurial by hand;
 ....

It's not a big fuss, and "insert Corecode's unofficial Mercurial
installation ruleset" stage will go away as soon as Mercurial will get
into pkgsrc.

Once it's done, the source can be checked out and Mercurial provides
fast updates, superb offline history browsing with changeset based view
and it eliminates the need of retrospective "src-051113{,.tar.{gz,bz2}}"
style source tree backups as it features fast forwards/rewinds of
the source tree and cheap (hard link based) clones for the case when one
needs two snapshots simultaneously.

So as an end user, I massively ignore what the main repo is stored in
as long as the Mercurial service is in place; the other POV is that of
the maintainers of the main repo -- I'm sure they will be able to figure
out what's the optimal for their purpose. (Oh yes, another POV is that
of mirrors, and yet another is that of the ones with a commit bit -- but
my [naive?] idea is that the VCS backend makes a difference mainly for
repo maintainers and end users [who do source based updates]).

Just my 2 cents.

Csaba