[OT] Q: what would you choose for a VCS today

Giorgos Keramidas keramida at ceid.upatras.gr
Thu Jan 31 16:00:53 PST 2008

On 2008-01-31 21:37, Stefan Sperling <stsp at stsp.name> wrote:
> I could not find any tool that does this properly among subversion,
> git, monotone and mercurial. That's not a big list, but I don't have
> time to try out version control systems all day. Also, proprietary
> VCS's were never considered (I also keep my freebsd kernels blob-free,
> call me a hippie or whatever if you want :P)
> Most tools seem to insist on trying to import the whole history of a
> CVS repository before they let you start doing any work in the newly
> converted repository. All conversion tools I've tried failed converting
> the FreeBSD repository.

Not really.  You can keep 'importing' snapshots of the src tree from any
arbitrary CVS branch, if you are willing to wait until CVS checks out
the first copy of the snapshot.

This is how we 'resync' with the official doc/ tree changes in the Greek
translation team:

    (a) We keep a Mercurial workspace which is read-only to everyone
else, except the importer.

    (b) The importer checks outs doc/ snapshots and commits them as
'vendor code drops' in http://hg.hellug.gr/freebsd/doc/

    (c) I pull changes from the 'import tree' into my own personal
workspace, and merge them with the latest translation effort text.

    (d) Then the merged tree is pushed to a second 'workspace', 'branch'
or whatever you prefer calling it, at http://hg.hellug.gr/freebsd/doc-el/

The whole process of importing clean snapshots is automated in a shell
script, which I manually kick off at this point:

% #!/bin/sh
% cd /ws/doc/bsd
% # 1. Start from a clean slate for the next import
% rm -fr *
% # 2. Check out a clean copy of a partial doc/ tree.
% cvs -d /home/ncvs co -d . -l doc
% cvs -d /home/ncvs -qR up -APd * share \
%     en_US.ISO8859-1 el_GR.ISO8859-7
% find . -type d -name CVS -exec rm -r {} +
% # 3. Update mercurial's idea of the current workspace state,
% # hg adding new files, and hg removing gone stuff.
% hg addremove
% # 4. Find out the $FreeBSD$ timestamp of the latest patch we are
% # about to commit.  Note that this may be a bit silly, because it
% # won't correctly detect -kb files being added after the last
% # $FreeBSD$ id change.  A better way would use -D to checkout from
% # CVS, so that a timestamp would be automatically known.
% timestamp=$( hg diff | grep '^+.*FreeBSD:' | \
%     sed -e 's/.*,v //' | awk '{print $1,$2}' )
% # Commit everything to Mercurial.
% hg ci -u ncvs -d "${timestamp} +0000" \
%     -m "Import FreeBSD doc/ snapshot at ${timestamp} +0000"

That's not something I would like doing manually several times a day,
but it certainly isn't impossible.

Naturally, similar scripting can be installed for Subversion, Git,
Bazaar, or darcs if that's your personal preference.

> Mercurial failed to convert the repo, too, and there was no way of
> telling it not to try to import the whole history either.

Snapshot-based import sof FreeBSD code as `vendor imports' are really
*VERY* easy to script in Subversion, Mercurial, Git and Bazaar.  Been
there, done that several times, and I can help you if you plan to do
something like this with any of the aforementioned VCSes.

> So far, this setup hasn't failed me, and the speed is several orders of
> magnitude higher than using CVS branches.

That's my impression too :)

More information about the freebsd-hackers mailing list