RE: General question on Serf

I think I can answer this question, but maybe one of the ra_serf gurus can
fill in the details.

With the get request serf sends a header to tell the server which version of
the file the client already knows. The server than usually sends the delta,
just like neon or svnserve do/did. The server is allowed to send the whole
file, but our implementation doesn't do this.

(We used to send the whole files early in HTTPv2 development because we
somehow missed this header and things got a lot faster when we fixed this).

                Bert

From: Mark Phippard [mailto:markphip_at_gmail.com]
Sent: woensdag 26 september 2012 15:14
To: Subversion Development
Subject: General question on Serf

I have a question about how Serf works that I keep forgetting to send to
this list.

When you do an update with Serf, my understanding is that it does a REPORT
request that gives it back a list of files that it needs to update and then
it fires off a bunch of GET requests to retrieve those files. With Neon,
the changes are all included in the REPORT response.

My question is how this intersects with Deltas.

Suppose I have a large text file in my working copy and someone has made a
small minor change to the file. When using Neon, I know that the client and
server just exchange a relatively small delta that is applied to my working
copy. I imagine this delta is part of the REPORT response that the client
receives.

What happens with Serf? From what I know, I would assume that Serf has to
do a GET of the entire file. Is this true or does it somehow only request a
delta? And what might this mean for real world performance.

Kind of a side question. One of the benefits of the Serf design is that
theoretically enables the usage of caching proxies between the client and
server. This is another reason I assume that Serf must request the entire
file. I do not see how a caching proxy would provide much benefit if the
Serf requests were for somewhat arbitrary deltas between two revisions.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/