lkml.org 
[lkml]   [2002]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: A modest proposal -- We need a patch penguin
    On Wed, Jan 30, 2002 at 07:48:35PM +0100, Ingo Molnar wrote:
    > eg. i sent 8 different scheduler update patches 5 days ago:
    >
    > [patch] [sched] fork-fix 2.5.3-pre5
    > [patch] [sched] yield-fixes 2.5.3-pre5
    > [patch] [sched] SCHED_RR fix, 2.5.3-pre5
    > [patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
    > [patch] [sched] entry.S offset fix, 2.5.3-pre5.
    > [patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
    > [patch] [sched] compiler warning fix, 2.5.3-pre3
    > [patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3
    >
    > these patches, while many of them are touching the same file (sched.c) are
    > functionally orthogonal, and can be applied in any order. Linus has
    > applied all of them, but he might have omitted any questionable one and
    > still apply the rest.
    >
    > how would such changes be expressed via BK, and would it be possible for
    > Linus to reject/accept an arbitrary set of these patches?

    There is a way to do this in BK that would work just fine. It pushes some
    work back onto the developer, but if you are willing to do it, we have no
    problem doing what you want with BK in its current form and I suspect that
    the work is very similar to what you are already doing.

    In your list above, all of the patches are against 2.5.3-pre5. If you did
    the work for each patch against the 2.5.3-pre5 baseline, checking it in,
    saving the BK patch, removing that changeset from the tree, and then going
    onto the next change, what you'd have is exactly the same set of patches
    as you have no. Literally. You could type the appropriate command to BK
    and you should be able to generate a bit for bit identical patch.

    In BK's mind, what you have done is to make a very "bushy" set of changes,
    they are all "side by side". If you think of a graph of changes, you started
    with

    [older changes]
    v
    [2.5.3-pre4]
    v
    [2.5.3-pre5]

    and then you added one change below that, multiple times. If you were to
    combine all of those changes in a BK tree, it would look like

    [older changes]
    v
    [2.5.3-pre4]
    v
    [2.5.3-pre5]
    [sched1] [sched2] [sched3] [sched4] [sched5] [sched6] [sched7]

    and BK would be happy to allow you to send any subset of the sched changes
    to Linus and it would work *exactly* how you want it to work. If we could
    get people to work like this, there are no problems. Just to make it really
    clear you would do this

    for p in patch_list
    do bk vi sched.c # that will lock it if isn't
    hack, debug, test
    bk citool # check it in and make a changeset
    bk makepatch -r+ > ~/bk-patches/patch.$p
    bk undo -fr+ # get back to the same baseline
    done

    Here's what people actually do. They make the first change, then make
    the second change in the same tree that already has the first change,
    and so on. BitKeeper faithfully records the linear sequence of changes
    and enforces that the changes propogate as that linear sequence. You can
    skip some at the end but you can't skip any in the middle.

    In your particular case, we really need out of order changesets to allow
    the second type of work flow and cherry picking. However, a fairly common
    case is that the changes are all in unrelated files and *even then*
    BitKeeper enforces the linearity. That's the problem I think we need to
    fix first, it's not a complete solution, but it is the 80-90% solution.
    Until we give you a 100% solution, you have to realize that you are making
    side by side changes and actually do it that way.

    If any of this is not clear to anyone, please speak up and I'll try and
    draw some pictures and add some explanation.
    --
    ---
    Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
    -
    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-03-22 13:15    [W:4.074 / U:0.412 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site