Greg Stein <email@example.com> writes:
> All right. Let me do this one more time.
> 1) if I only receive delta windows, then I can't know whether the
> Content-Type is application/octet-stream ("plain text") or
As Karl said, why can't you:
* add a field to svn_txdelta_window_t that indicates the content-type
* make svn_txdelta_apply() generate window-consumers that understand
* add a "content-type" argument to svn_txdelta() so it will produce
a window stream in the format you like.
This is a tweak to the existing system... seems more elegant to me
than a total inversion of the interface.
> 3) I cannot enable "send plain text all the time"
> 4) I cannot choose a different diff format for the wire.
This tweak should allow you to accomplish your points #1, #3, and #4.
> 2) the delta window model is "push-to-editor". the network code works best
> with a "pull-from-source" model. in fact, we may not even get Neon to be
> able to work with the push model, except by buffering everything into
> memory first.
This is the only point that scares me. Yikes. Is this a real
I'm confused about this, because neon is acting as an HTTP client and
mod_dav_svn is acting as the HTTP server. Don't HTTP clients "push"
requests at servers, and servers respond? How could mod_dav_svn
possibly "pull" data from neon? That seems like a backwards HTTP
model to me. Maybe you can clarify.
> (this buffering in memory will be happening for M2, btw; don't go commit
> 100M files unless you can hold that in memory on your client)
Heh, this is happening anyway within the client *and* fs libraries too.
It will all be fixed, no worries. :)
Received on Sat Oct 21 14:36:26 2006