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
    * Larry McVoy <lm@bitmover.com> on Tue, Apr 16, 2002:

    > 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.
    >

    That's cool. That's what should be in a SCM. I guess we may have a
    misunderstanding where I say "drop-in tree" and you assume I mean using CVS
    to tag and branch a subset of the kernel source? The drop-in tree is what I
    described in my initial response to you so many posts ago. It doesn't have
    to be specifically tied to a CVS-centric mode of development, but before some
    of the other SCMs came into fruition, CVS was the easiest (or most popular
    if you insist it wasn't easy) way to do it. Now we have advanced SCMs
    available, and I hope to use one that will still support drop-in trees
    while allowing me access to all the whizbang features that will make my
    life easier.

    > > 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'd hate to sound like I'm trolling or being a broken record. But I don't
    currently have that option with BK. This is the option I want, to be able
    to not have to worry about pulling all changes or being able to cordon off
    only the bit I want/need to work with. See the above as to why CVS isn't
    just the means, it's just the tool currently used for drop-in maintenance.
    Give me proper drop-in support using BK (or any other modern SCM tool), and
    I'm sold.

    > > 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.
    >

    When my drop-in tree file changes upstream, I'll find out in the next
    upstream sync. Obviously if my drop-in tree is current, that file hasn't
    changed yet. File renames are broken, but I never pretended they weren't. I
    guess what you're saying is it comes down to me weighing out feature-rich
    set vs. feature-less set, where BK is the former, and I should expect to have
    to sacrifice my entire development model (drop-in trees, not CVS) for the
    bloated model that BK currently *enforces* (see your above paragraph about
    having the option).

    > > 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.
    >

    This was already being done with the satellite projects and drop-in
    trees, but didn't have the benefit of being SCM-controlled *globally*. I'd
    very much like to see this happen. Was there any timeframe on this or
    should I just start searching lkml archives?

    >
    > > 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.
    >

    Nope, I said that based on what I read at www.bitkeeper.com, BK didn't
    support drop-in trees *today*. I said that the last time I actively used
    the tool was 2 years ago, but I haven't had a reason to use it since then.
    In a public forum, which you use to promote sales and use of your product, I
    stated quite simply and plainly that BK won't allow me to do drop-in trees,
    with the simplicity of CVS. Even using a full kernel source tree as CVS
    HEAD and branching subsets of HEAD into small drop-in like branches does
    what I need to do in CVS. This is even before you start worrying about
    automerging and file renaming - I can't do the above using BK - for kernel
    development.

    Two years ago, or today, BK still doesn't do it, not without requiring
    massive structural changes to the master repository by the project owner -
    not the satellite maintainers. This requires a significant amount of
    planning ahead and effort from Linus (or whoever ends up doing it), where
    using the drop-in tree model that burden is placed on the satellite
    maintainer. When I decide to start and maintain the "linux toaster
    driver", I pull out the source I need from mainline, and setup my drop-in
    tree from that and my new imports. The BK way to do it is to simply "clone
    the master" and work from that. Not a drop-in.

    I voiced a legitimate concern about why drop-in trees were useful, and why
    I wouldn't be able to contiue their development using BK. You proceeded (for
    a couple of posts at least) to dodge that concern with arguments of why CVS
    pales in comparison to BK. That I didn't really care about, and maybe you
    should be asking yourself, "If I didn't have the correct answer and I can't
    accurately address this guy's concern, why did I bother replying in the first
    place?"

    > 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
    >

    Right. We can't do it, only the repository owner can. By your own
    admission the drop-in tree as I described it isn't supported:

    "Ahh, OK, we're already working on this. We call 'em nested repositories
    and one of the problems they solve is exactly the problem you described.
    Think of them as CVS modules, with a little more formality, and you're
    about there. They also solve a bunch of performance problems."

    The "csetprune" command you've pointed me to apparently doesn't do this.

    > > 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.
    >

    Yep, you're correct, except about the handwaving part. Last I checked, 2.2
    was still being maintained, and 2.4 is also being maintained. Believe it or
    not, I have to be bothered with tracking changes between all of these
    versions *and* 2.5, and at least the 2.2 variant still needs to be done by
    hand. 2.4 and 2.5 are now SCM-controlled by BK. That's great, and I'm
    being serious here. But it can't cope with the drop-in style, and at this
    point I can't be coerced into a new mode of development. If BK could sanely
    handle drop-in trees (the right way), trust me, I'd already be using it. But
    I'm still forced to do the merging work by hand, if I insist on maintaining
    the drop-in tree (without CVS), even if using a BK clone as my source base.

    My tool needs to do what I tell it to, not the other way around.

    > > 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.
    >

    If you were able to propose a sane way to continue using the drop-in model
    using BK, then I'd have no problems taking you seriously. My only claim
    was that BK couldn't handle drop-in trees. I didn't say it sucked overall
    as a SCM or that I wanted to protest because it wasn't open. The "work" was
    me perusing the bitkeeper webpage, and going back and forth with you, the guy
    I thought would be the most intelligent on all of BK's features. Are you
    saying the only way for me to evaluate a tool (one that I haven't used in
    ages) is to use it? I can't rely on documentation or peer reviews and
    comments? Wouldn't my time be spared if you just told me what it would or
    wouldn't support?

    > 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.
    >

    This?

    http://www.uwsg.iu.edu/hypermail/linux/kernel/0202.2/1060.html

    It was a good read, and easy to follow, but it still does the opposite of
    what I need to do. I want multiple small project-specific trees, not a
    myriad of full kernel trees. Everything else gave me a good starting point
    for doing SCM-controlled kernel development using BK. Thanks for the
    pointer.

    > 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.

    Point taken about the drop-in tree being a hack, when used within the
    limitations of CVS. With a SCM that could do it intelligently, it would be
    overly useful, but unfortunately BK can't do it at all (or, it does it in
    the complete reverse).

    I already have been looking at alternatives to CVS that would allow me to
    maintain a master kernel source repository with many satellite "branches" that
    would be equivalent to small drop-in trees for the various kernel ports and
    subsystems. I would also need a reasonable way to do merges between the
    satellites and the trunk, and being able to do it locally with cloning would
    be a major plus.

    I've found that Arch comes the closest to what I need, so I've been "doing
    my homework" with it. When I do run into snags, or when Arch trips over
    itself when I'm trying to maintain my satellites at least I do have the source
    instead of the requirement that I bitch to you about missing functionality. I
    suppose for the project I'm working on, once it gets to the point where I
    need to grab up to the minute changes, I can be bothered with setting up
    either an Arch<->BK gateway or find another means to migrate updates from
    the latter.

    If BK can gain (intelligent, where satellite maintainers can split, not
    just root) drop-in support to where it doesn't make sense for me to use
    Arch for Linux kernel projects, I'd start using it (and recommend it) for my
    satellite projects immediately. Again, for me it boils down to using the
    best tool for the job.

    M. R.
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2005-03-22 13:25    [W:2.425 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site