lkml.org 
[lkml]   [2005]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Kernel SCM saga..
    Date
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-07 20:00    [W:4.392 / U:26.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site