> > Fourth, non-null pulls are similarly faster, again, by design. BK only
> > moves the data it needs to move. That means if you have a 100GB file
> > in which you have changed one byte, BK will move on the order of 1 byte
> > to update that file. And that's it - it doesn't compare the two files,
> > or read the two files, or in any way look at the two files to figure out
> > that they need to be updated.
>
> This is an interesting point. As far as changes are concerned, it should
> have lower network utilization. However, in effect, it does compare the
> files. It compared the file when you checked it into your local
> repository. It's just shifting the burden of the comparison to a local
> repository instead of doing it over the network. Faster, yes, but it
> still does the same thing, just in a different way that uses less
> bandwidth.
You just summed up one of the main reasons why BK is better. We shifted
work to the client. There is one server and many, many clients in a
CVS tree. The same problem solved using BK inherently distributes the
load over all the machines, moving 99% of to the clients and off loading
the server (and hence the network) almost completely.
BitKeeper isn't any faster than CVS when you do the same operation, or at
least not much faster. If we both have 10,000 files we have to update,
we're both going to be doing a lot of work. In fact, I suspect that CVS
is faster at that than BK is because it is just updating a clear text file
and we are updating a revision history - we have more work to do so it
stands to reason we'd be slower.
BitKeeper is faster in practice because it isn't trying to talk to the
CVS server for all of the operations. By far the vast majority of the
operations never reach out across the network. So on a slow client,
BK is slow, on a fast client, BK is fast. By contrast, with a slow CVS
server, both a slow and a fast client are slow.
So perhaps a better way to look at it is that if you can afford decent
hardware, your life should be quite pleasant using BK. Our definition
of decent, for Linux kernel repositories, is a 466Mhz celeron with at
least 256MB, and you really want 384. The kernel is about around 120MB
checked out, the revision history is about 160MB, and you need some mem
for the inodes. CVS is lighter weight in that respect, it just needs
the 120MB for the checked out files and some mem for inodes. But the
difference in price is reasonable and if we have to buy memory for the
kernel developers, we'll do it once we can afford to do it. It's _really_
nice to measure your operations in seconds rather than minutes.
-- --- 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