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/