lkml.org 
[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Darkstar Development Project
On Mon, Sep 11, 2000 at 06:49:43PM -0500, Jonathan Lemon wrote:
> I don't know why I'm bothering to reply to this, but yes, if you're
> trying to synchronize CVS source trees with only CVS, it will be slow.
> Now, if you were to compare CVSup vs Bitkeeper, then things might get
> more interesting.
> --
> Jonathan
>
> (for those unaware of it, CVSup is a high-speed mechanism to
> distribute CVS repositories, and uses several algorithms including
> "rsync" to accomplish this.)

I'd be happy to do this. I've already gone over the details in private
mail with Dave Miller, he was suggesting something similar and I explained
how much disk & net I/O you have to with each case and the BK case is
dramatically less.

The reason is that BK does all the work when you do a local commit, it
captures the state of the entire tree once, at the time you commit your
changes. CVSup, rsync, CVS, etc., all have to look at the whole tree
because there is no fanin/fanout like BK has with the ChangeSet file.
You can play all the games you want, but the bottom line is that you
have to look at some version of the data, be it all the inodes, or the
actual data. With BK, we've distilled the state of about 9,000 files
in the Linux tree down to about 6,000 bytes. We have to do a single
roughly 32KB disk I/O to get that state and then we compress to 6K and
transfer it across the wire.

No matter what you do with rsync, there is no bloody way you can even
come close to a single 32K disk read and then a 6K over the wire transfer.
At least, I can't think of one, can you?

We do just as much I/O on the commit, then we walk the tree, and diff
against the checked in version, so if you have the entire tree editted,
we'll diff the entire tree. But that happens when you commit your
changes, not every time you update.

The fundemental observation is as the tree size/age grows, the amount of
change you make to it stays relatively constant but the updates grow with
tree size. One human can only make so much change, but many can make a
lot. BK takes advantage of that and does the hard work when you do hard
work, not every time you update.

It's just a different design, no offense is intended against CVS, we have
all used and learned from CVS. But just because CVS is useful doesn't mean
it is the best answer.
--
---
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.037 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site