> The timing is typical over repeated tries. The GCC tree contains 98.1
> megabytes of data in 9105 files, 532 directory. A little more than
> Linux (but I don't have an unpacked fresh tree to count for sure).
>
> I'm not going to try touching all the files.
>
> Conclusion: CVS is pretty fast when not many files have changed.
> Comparable with BK. Just don't touch all your local files!
That's right but not exactly very helpful for developers, I would expect.
The problem is that it works as long as you are a read only CVS user
but as you do work, it gets slower and slower. That's a problem - it
means that the very users that have the greatest need for it to be fast
(the active developers as opposed to the read only folks), get punished
the most.
Don't get me wrong, I am fully aware that by far the vast majority
of CVS work areas are read only, in fact, I'd guess it would be more
than 99% of them. And it's nice that CVS is fast for all those guys.
But the point is to help the *developers*, i.e., Linus & Co, and those
guys tend to have trees with changes a lot of the time. I don't care if
the difference is 2x or 50x, I don't want the tool to be even 2x slower
for Linus than it is for some read only guy. And more importantly,
Linus isn't going to use any tool that slows down as you start to do
real work with it.
And I'm not saying BK is fast enough, in many cases, I'm pissed that it
isn't faster and we're working on it, and will keep working on it until
it can't be any faster. It's fast enough when you can imagine the best
way to solve a problem, count up the number of disk accesses required
for that solution, count up BK's disk accesses, and there isn't any
difference or only a very slight one. We aren't there yet, but we're
working on it.
-- --- Larry McVoy lm@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 Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:16 EST