Messages in this thread |  | | Date | Mon, 11 Sep 2000 19:14:59 -0500 | From | Jonathan Lemon <> | Subject | Re: [ANNOUNCE] Darkstar Development Project |
| |
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/
|  |