On Mon, Sep 11, 2000 at 05:05:08PM -0700, Larry McVoy wrote:
> 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.
Oh, no disagreement there, CVS has quite a few shortcomings, so I'm
in no way holding it up as anything near an ideal solution, it's just
what we have now. And yes, the cvsup daemon will take quite a bit of
I/O and memory as well. I merely pointing out that a comparision of
cvsup vs BK would be far more interesting than native CVS alone.
-- Jonathan - 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