lkml.org 
[lkml]   [2002]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Linux-fbdev-devel] Fbdev Bitkeeper repository
    On Wed, Apr 17, 2002 at 12:04:12AM -0500, M. R. Brown wrote:
    > Not sure I follow here, you're a bit vague about "doing the same thing".
    > Do you mean syncing from the mainline kernel?

    Syncing from the main kernel, synching from someone else, syncing with
    a coworker, whatever. It doesn't really matter. With the limitation
    that BK wants you to eat everything that the other guy has that you don't,
    it all just works. And you can sync from N different places all of which
    happened to have the same patch in the same changeset, and it gets applied
    once, BK knows it has it already.

    BK isn't perfect, but you are looking at it through CVS colored glasses.
    Take 'em off, it's got some stuff that will save you time and effort.

    > For the LinuxSH project, we moved from tracking the full kernel tree (via
    > CVS) to a drop-in tree structure mainly because of the difficulty in
    > tracking all upstream kernel changes at once. It wasn't really related to
    > what CVS did or did not offer.

    Disagree. CVS sucks at tracking an external source of change while
    maintaining your own changes at the same time, in the same tree.
    It really sucks at that, you are forced into a broken branching model
    with awful merge characteristics. Try the same thing with BK, it's
    a lot nicer, most stuff just automerges, and the stuff that doesn't
    only needs to be merged once. Your claim that it isn't about CVS
    doesn't make much sense when CVS forces you to split your subtree
    out. Having an _option_ to do that is one thing, being forced to
    do it is another.

    > I never said anything about working in isolation in any of my posts. A
    > drop-in tree is only usable when "dropped in" or symlinked on top of a full
    > kernel tree.

    And if that tree has changes in the files that you are "dropping in"?
    You just stomped on them. Or you are left with an even more broken
    merge model than CVS. And what about file renames.

    > Also, the size of a drop-in tree is a side effect of its composition, it
    > was used to illustrate the benefit of the simplicity of drop-in trees - if
    > you recall the introductory paragraph of my original reply to yours, I said
    > that drop-in trees are most useful for kernel subsystems and backend
    > (architecture) ports.

    Agreed. We're headed towards breaking up the kernel tree into
    subrepositories for that reason.

    > However, I do mind how much of my broadband bandwidth is used
    > (since I'm stuck with a flaky ADSL link) and I'm sure developers still on 56K
    > links also mind.

    BK's pretty stingy with bandwidth. I think the openlogging tree has
    some problems, but other than that, BK uses very little bandwidth, far
    less than CVS. It knows what needs to be transfered, CVS has to look,
    over your net connection. We have lots of people tracking the kernel
    trees via a modem. You can play games to save more bandwidth too,
    if you know you have a common gca in a local tree, and you want to get
    a local copy of some other "branch", clone -r back to the gca and then
    pull from the branch into the new repository. You'll save transfering
    all the stuff that you already had.

    > So, splitting trees in BK. Do you mean by using native BK commands, or by
    > planning ahead and using multiple repositories? Perhaps when you've
    > finished flaming me and defaming CVS you can give me a valid response as to
    > how one would maintain a drop-in tree using BK.

    Perhaps when you have finished flaming me, you can go use the tool, read
    the docs, and learn what it can do. Part of the problem I have is that
    you are, in a public forum, saying that BK is this and that, based on your
    perceptions from 2 years ago when you said you used it on the ppc tree.
    I can't imagine that you used it very much, because there is not a
    single changeset in the tree with your login on it. So maybe you are
    making your comments based on a 2 year old reading of the docs, rather
    than actually using it. That is pretty annoying and a waste of time.
    Go learn the tool, if you want an education, then buy some training.

    As for splitting trees, "bk help csetprune". It not only splits trees,
    it maintains the repository changeset history graph, no small feat.
    But it's a 1-way, 1-time operation, you can't unsplit. So it's something
    that I suspect will happen when Linus wants it.

    And you could find this information by

    http://www.bitkeeper.com
    click on search
    type in "split"
    hit return,
    it's the 3rd item down.

    > You seem to be stuck on "why CVS sucks" while I'm trying to convey "why CVS
    > does what I need it to do" as far as drop-in trees are concerned.

    Except it *doesn't* do what you need it to do. You proceeded to hand
    wave over the many places where CVS won't work. You haven't addressed
    either of the two big problems, renames and content changes in the
    upstream tree. In the 2 months of usage, Linus' tree has seen 1289
    renames, of which 767 where real renames, not deletes. How does your
    drop in model handle those? What about content changes that you don't
    have yet, how does it handle that? In both cases, the answer is "it
    doesn't". So you are doing work that you don't need to do, by hand.
    That seems misguided when there is a tool that will do that work for
    you.

    > conditioned to attack (or belittle) anyone that doesn't accept BK as
    > gospel. I understand taking pride in your work, but damn! Take it easy.

    It's got nothing to do with gospel, it's got everything to do with you
    making claims based on no work on your part, not even recent usage.
    BK isn't anywhere near Linus' definition of the best (i.e., it can't
    get better). Nowhere near. But it's quite useful if you figure out
    how to use it. And we're making better as fast as we can.

    Contrast your comments / homework with Jeff Garzik, just for fun. BK
    has some limitations he didn't like, so he asked a few polite questions,
    figured out how to work around the limitations, and wrote it up in a
    doc (have you read it?). His approach has been widely adopted, there
    are at last count around 130 slightly different BK trees sitting on
    bkbits.net.

    In summary, because I've had enough of this thread, your drop in tree
    is a hack, it doesn't handle even the basics of SCM, and you haven't
    shown how to handle those. BK has plenty of problems, but it least it
    handles the basics. What you are doing is like working in a file system
    which makes you edit the raw disk to do renames and/or content merges.
    --
    ---
    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:22    [W:0.033 / U:1.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site