I trimmed the CC list a bit, it was getting large. I just left
linux-kernel since I believe everyone is on that list.
} It's this critical mass which is missing; otherwise, my custom scripts
} which use RCS and where I only check in those files which I modify are
} quite frankly, more convenient right now. BK makes me have to think too
} hard, where as CVS and RCS are more intuitively obvious what's going
} on. That comes from familiarity and long experience, and I have no
} doubt that if I were using BK a lot, I'd get familiar with it too.
The above tells me you haven't tried BK and stayed with it very long. It's
been intuitive for doing simple things and almost the same is true for
complicated things. CVS for the kernel is a nightmare compared to BK.
I've had to go back to CVS for some linux/mips work (linux/mips is managed
mostly through CVS, not my choice) and it's been a mess. Why don't you
send me some private email with exactly what you want BK to do that's not
intuitive and I'll walk you through how I do it. I think you'll see the
difference right off.
I'm a big fan of BK. I've been managing the PPC trees, our RTLinux trees
and it's helped out a LOT.
} The problem though is time. I took a full day's worth of my time trying
} to play with BK. That was a significant investment on my part, since I
} could have done a lot of other things with that time. And in order for
} me to get really familiar with it, I'll have to spend more time. But in
} the mean time, for the projects where I was using it, I was pretty much
} a solo developer, and if that's all I'm doing BK has no real advantage
} of using CVS with a local repository. (Which is why it was very astute
} of you to give solo developers the option of using BK without openlogin
} if they so desired.)
}
} Now multiply my experience by the several hundred kernel developers out
} there, and you can easily see how the kernel development community could
} easily have to invest a man-year or more learning how to use BK. But
If it takes a man-year to learn BK, that person shouldn't be doing kernel
work. It's beyond them. Putting shoes on would be a monumental effort of
mental power for them.
BK isn't CVS, RCS or any other revision control software. It aims to do
things differently - and better. There is some learning, but it is far far
from a year. It took me 2 hours to get to the point where I was
competently creating trees and giving other people access to our trees.
That includes merging in Linus' patch with the _weird_ pre-patch format -
that's not such an easy thing.
My experience isn't unique. All of our PPC guys have caught up to speed
very very quickly.
} there's catch-22, in that if we don't have a critical mass of people
} using it, then the value of BK is seriously diluted. So when I invested
} a day of my time learning how to use BK, that was a decision that made
} economic sense only if I thought eventually that a lot of other people
} would use it. Unfortunately, the bug-a-boo with the license, and the
} fact that some people (and I respect their right to feel that way) don't
} feel comfortable with the BK license, means that I may have made a bad
} choice economically when I made my decision to learn more about BK. (Of
} course, there were other reasons other than pure selfish economic ones;I
} was curious, and I think Larry's a good guy, and they both weighed in my
} decision to spend time learning more about BK.)
}
} I recall the old story of penguins lined up at the ice floe's edge, each
} nudging each other to see who would be the first one to jump.
} Eventually one would get pushed in, and if he/she wasn't eaten by a
} shark, they would all jump in and they would all get fat and happy.
} There seems to be nice parallel to this situation.
I hate mixing metaphors on the kernel list since they tend to degrade into
discussions of social-Darwinism, bunnies, bazookas and wolfs with
IT-manager claws (check out the kgdb thread). So I'll avoid the penguin
jumping in metaphor. I did take the leap to BK, and took the PPC and
RTLinux guys with me. We plowed the path for Linux work with BK already.
We've several pitfalls, influenced BK enough to remove some problems (Larry
has been really accommodating) and I'd recommend it to nearly anyone.
Linux BK doesn't depend on Linus using it. If it did, I wouldn't be using
it. We've been tracking Linus for nearly a year, merging with him, taking
patches from BK and non-BK users and it does work.
You don't even need to track Linus yourself. You don't have to create a
tree, either. Just clone the tree we've been maintaining to track Linus
(2.2 or 2.4/2.3) and you have your own area to work in. I'm serious about
sending me the troubles you have so I can help. I bet you'll like it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:24 EST