Re: Kernel SCM saga..

Daniel Phillips
2005-04-07T17:55:29Z

On Thursday 07 April 2005 13:10, Al Viro wrote:
> The point being, both history and well, publishable result can be expressed
> as series of small steps, but they are not the same thing. So far all I've
> seen in the area (and that includes BK) is heavily biased towards history
> part and attempts to use this stuff for manipulating patch series turn into
> fighting the tool.
>
> I'd *love* to see something that can handle both - preferably with
> history of reordering, etc. being kept. IOW, not just a tree of changesets
> but a lattice - with multiple paths leading to the same node. So far
> I've seen nothing of that kind ;-/

Which is a perfect demonstration of why the scm tool has to be free/open
source. We should never have had to plead with BitMover to extend BK in a
direction like that, but instead, just get the source and make it do it, like
any other open source project.

Three years ago, there was no fully working open source distributed scm code
base to use as a starting point, so extending BK would have been the only
easy alternative. But since then the situation has changed. There are now
several working code bases to provide a good starting point: Monotone, Arch,
SVK, Bazaar-ng and others.

Sure, there are quibbles about all of those, but right now is not the time for
quibbling, because a functional replacement for BK is needed in roughly two
months, capable of losslessly importing the kernel version graph. It only
has to support a subset of BK functionality, e.g., pulling and cloning. It
is ok to be a little slow so long as it is not pathetically slow. The
purpose of the interim solution is just to get the patch flow process back
online.

The key is the _lossless_ part. So long as the interim solution imports the
metadata losslessly, we have the flexibility to switch to a better solution
later, on short notice and without much pain.

So I propose that everybody who is interested, pick one of the above projects
and join it, to help get it to the point of being able to losslessly import
the version graph. Given the importance, I think that _all_ viable
alternatives need to be worked on in parallel, so that two months from now we
have several viable options.

Regards,

Daniel