On Fri, Feb 01, 2002 at 03:47:16PM -0500, Rob Landley wrote:
> That's my impression, anyway. (A few years out of date now.) My experience
> with the source control system was that it DID have the complete revision
> history in it going back to the 1980's, but it was far more work than it was
> worth to try to mine through it to find something ...
bk revtool
double click on the last rev, brings up an annotated listing,
click on a line, brings up the checkin comments for that line,
double click on a line, brings up a changeset viewer showing the
entire patch which contained that line.
Now tell me, Rob, wouldn't you find that useful? I find it useful,
I find it extremely useful, I can fix bugs a factor of 10 (at least)
faster with it than without. Not having it is like not having ctags,
how the hell do you find anything?
> specifically looking to place blame and prove something wasn't YOUR fault.
Only losers need to go look to place blame. Programmers fix bugs. This
information dramatically improves your ability to fix bugs. If you
programmed more and talked less, you might understand this concept.
> I.E. yes, I think we honestly do want an easy way to limit the granularity of
> propogated diffs.
So suppose I'm joe developer and I make 10 changesets to add some feature.
Somewhere in there I caused a problem. The changesets have been collapsed
so I now have to wade through all of them to figure out what the problem is.
If I had all of them, I could
bk clone
while true
do
make
test_for_bug || break
bk undo -fr+
done
which quickly walks through all of them and finds me exactly the one that
caused the problem.
The more I collapse, the harder this is. But wait, you say, if BK lety
me do it both ways, the original developer has all this detail. Great,
that means we took a system that could let the whole world figure out the
problem and we made it so only one guy can do it fast. Not real smart.
I'm sympathetic to the "wait, I made this changeset and then I found
another bug" problem and we have a command that lets you reedit a
changeset. And we're talking with Linus about making that even more
flexible. But the rules are you can only change history on things you
haven't propogated.
If you want to help make BitKeeper better, it would be a lot more
productive if you used it and figured out how it really works instead of
critizing how you think it works. It's a lot closer to what you want than
you think it is, and it is much closer than any other system in the world.
-- --- 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/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:20 EST