Re: Moving to bzr?

[Stefan Monnier]

>> The decision to move to bzr was made, but the decision when to move
>> was not.
> Some kind of timeline, even if we're forced to move it back
> eventually, would be nice.

I think I wrote this a few weeks ago, but here it goes again:

I've been using Bzr for a while now for my main development branch (from
which I then extract patches which I apply to the CVS tree and then
commit).
Speed isn't impressive, but in my situation (5MB/s DSL, cpu speed
between 1.2 and 2.4 GHz, RAM between 768MB and 4GB), it's proved to be
comparable to CVS.
The initial checkout may take a longer time, but I did it once many
months ago and have never had to do it again since, so it doesn't
seem important.

On the reliability side, I've been using the development branch of Bzr
(upgraded on a non-regular basis), and have not encountered a single
problem (other than the fact that it tends to crash the NFS client if
your Bzr branch is on an NFSv4 partition using Kerberos: supposedly the
Bzr code that triggered this bug has been changed so maybe the problem
is gone, and hopefully the underlying NFSv4 bug has also been fixed or
will be fixed soon, tho from what I hear, the state of NFSv4+Kerberos in
the Linux kernel is not very inspiring).

>From that point of view, I think we can switch any time now.

The main remaining problem is to come up with a good Bzr repository: the
one I've been using (maintained by Jason Earl) has some missing tags,
and lacks merge history as well as file-move information.

Apparently the file-move info will be difficult to recover, so I think
we will have to live without it (note that we live without it in CVS,
but some of that info is available (and used) in the Arch repository).

The missing tags should be easy to recover.  And the merge history is
available in the Git repository, so there's hope to get it into a Bzr
repository as well.

I.e. we're just waiting for a good Bzr repository with complete tag
data, and with as much merge history as we can get,


        Stefan