On 30/03/2010 20:33, Arthur Corliss wrote:
On Tue, 30 Mar 2010, Matija Grabnar wrote:
Er, not exactly. Read
http://www.cvsup.org/howsofast.html
I had read http://www.cvsup.org/faq.html#features item #3.
From what I can see, cvsup uses the rsync algorithm on a file-by-file
basis (it uses just the differential send part of the rsync
algorithm). It doesn't rsync the whole tree, which was what I
understood to be the original problem (wasn't the complaint about the
flood of stats?).
Sounds like I may have interpreted the FAQ incorrectly, then. Thanks for
pointing that out. I have a few question, though: the explanation says:
"At the same time, the Tree Differ generates a list of the server's
files."
That seems to infer that it's doing the exact same thing as rsync, so
all the stats are still present on the server, right?
Nowhere do I see it mentioning that the daemon is maintaining state between
requests. The primary speed-ups (beyond special file update handling) is
better use of bidirectional bandwidth.
Well I do know the client has a .sup file that runs into the dozens of
megabytes for each kernel tree you track.
If you want to avoid a stat storm you are going to trade stats for disk
space, by way of a cache. And that may be what these sup files are, but
it may also be a red herring (they look like CVS descriptors).
I've never dived into the protocol. The fact that the client is written
in Modula-3 scares me.
Do you have access to a cvsup server so you can verify its behavior?
On any FreeBSD machine that syncs the kernel tree. If you're stuck, send
me an SSH public key (RSA >= 2048 if possible, non-blank local pass
phrase) and I shall set you up.
David
--
There's bum trash in my hall and my place is ripped
I've totaled another amp, I'm calling in sick
