Greg Stein <gstein@lyra.org> writes:
> > (2) Suck! Does that mean we're always GETting the whole file even
> > if one character has changed?!
>
> Yes.
>
> [...]
>
> Now... regarding fetching of diffs. That gets much tricker. We have to
> generate some additional headers in the GET request that tells mod_dav_svn
> "I have <this> revision *and* I can accept <these> diff formats, so send me
> a diff." We would then generate a diff somehow and send it down the wire.
>
> One of the key indicators that you did not get a diff is the Content-Type
> header in that response. When a diff is sent, the C-T will reflect that.
Hmmm. I realize that the current state of affairs is just to get the
network layer up and running, and does not necessarily indicate
anyone's preferred design.
So I'm asking here about our eventual goals for this aspect of the
network layer. These questions are mainly for Greg Stein, network
layer guru, though others (Ben, Mike) can actually do the work if
desired.
Currently, we have this:
1. Client sends a wc summary to server.
2. Server sends essentially a "skelta" (skeleton tree delta) back,
saying what needs to be changed, but not including actual diff
text or fulltexts.
3. Client uses the list provided in (2) to do a series of GETs.
Currently, the GETs get fulltexts, not deltas, but this is
planned to change.
The next level of optimization, along the path of least resistance, is
to change (3) such that:
3. Client uses the list provided in (2) to do a series of GETs,
each GET retrieving a diff (probably svndiff).
This is an improvement, but it's still far from ideal, because it
involves at least one extra network turnaround. Am I correct in
assuming that the final goal is:
1. Client sends a wc summary to server.
2. Server sends back a tree delta, complete with diff data. The
diff data is infix, not postfix, so that an interrupted update
is still useful, instead of being an all-or-nothing affair.
?
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:42 2006