[lkml]   [2005]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux
    Linus Torvalds wrote:
    > On Sat, 5 Mar 2005, Jeff Garzik wrote:
    >>Yup, BK could definitely handle that...
    > However, it's also true that the thing BK is _worst_ at is cherry-picking
    > things, and having a collection of stuff where somebody may end up vetoing
    > one patch and saying "remove that one".

    In general, I agree. Andrew and I mentioned this to BitMover recently
    [though its certainly not a new comment], when they asked us why I had
    to occasionally blow away the netdev-2.6 tree, and reconstitute it from

    > I love BK, but what BK does well is merging and maintaining trees full of
    > good stuff. What BK sucks at is experimental stuff where you don't know
    > whether something should be eventually used or not.

    I use BitKeeper to maintain such a tree, "libata-dev". Most stuff in
    there will go upstream. Some stuff may never go upstream. Some stuff
    needs to simmer for a while before going upstream. So "change streams"
    get divided up locally:

    [jgarzik@pretzel libata-dev]$ ls -FC
    adma/ atapi-enable/ janitor/ remove-one-fix/
    adma-mwi/ bridge-detect/ passthru/ sata-sil-irq/
    ahci-msi/ chs-support/ pdc2027x/ tf-cleanup/
    ahci-tf-read/ ioctl-get-identity/ pdc20619/ via-6421/
    iomap/ promise-sata-pata/

    and then I cherrypick from that.

    netdev-2.6 queue is maintained the same way. It's simply a merge tree
    composed of 40+ individual trees, all merged together.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:10    [W:0.021 / U:4.168 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site