move rsync development tree to BitKeeper?

Martin Pool mbp at
Thu Dec 6 18:18:44 EST 2001

Andrew and I thought it might be an interesting experiment to move
rsync to using BitKeeper rather than CVS for source code control.  

For a project with rsync's size and activity CVS is actually fine, but
it would be a nice "toe in the water" with BitKeeper to get some
practical experience before possibly using it on larger projects.  BK
is moderately well-proven on open source projects including MySQL, the
PowerPC Linux kernel port, and the ext2 filesystem, although of course
it's not nearly so widely used as CVS.

You can find a lot more information about the differences here:

BitKeeper is not strictly Open Source, but arguably good enough.

The proposed plan is to convert the existing repository, retaining all
history, some time in December.  At this point CVS will become
read-only and retain historical versions.

Developers with write access will be able to modify the code using
BitKeeper-over-ssh, similarly to the way we use cvs-over-ssh
presently.  (At the moment I think this only really applies to Dave,
Andrew and myself.)  This will mean installing a BitKeeper client on
your development machine.  I found it took a couple of hours to get to
know it -- most of the concepts about code control carry across quite
directly from CVS.  Binaries are available for many platforms, and
source is available to cover the others.  I think BK is sufficiently
promising to justify the investment.

Non-core developers and other users will be able to access rsync
source as at present by

 - downloading release or release-candidate tarballs

 - rsync from an unpacked source tree

In addition, we will offer anonymous read/only BitKeeper access, and
BK/web corresponding to CVSweb.  We may maintain an anonymous CVS
read-only tree based on the BK tree if there is sufficient demand.

As at present, we welcome contributions in diff form from interested
developers in the community.  In addition to plain diffs, if we move
to BK we will also accept diffs with BK metadata annotations, which
will be a slightly more systematic way to manage them.

I will probably set up a r/o BK copy of the tree sometime in December
to let people try it out.  If we decide to switch there will be a flag
day at which CVS becomes readonly and BK writable.  If it turns out to
be a fiasco we can switch back to CVS.

I don't think the change will be too disruptive, but of course I
wanted to consult before moving.  Please send any comments to me or to
the list, whether they be "it's great, let's do it", or "I don't have
time to switch."  (If you need to flame about the licence then please
send it direct to me rather than burning up the list.)


More information about the rsync mailing list