Greg Hudson <ghudson@mit.edu> writes:
> I was going to have a go at the editor which outputs XML, but:
>
> * Uh, where do I find a description of what XML elements I
> should be outputting? This is the big roadblock.
Well, there's one description (which, for questionable reasons,
doesn't completely admit it's XML, but it is) in the section
``Deltas'' of the design document. Karl and Ben have been fiddling
with that stuff more recently than I have; I don't know if they've
written up their latest thinking.
> * Karl's framework has this variable postfix_text_deltas.
> What is it for?
The idea is that you could transmit a complete tree delta, but instead
of including the text deltas exactly where they appear, you could just
include a reference number, and go on with the tree delta. Then,
after the tree delta is all done, you can send the text deltas,
identified by reference number.
What's the benefit? Well, we're assuming that the bulk of most tree
deltas will be in the text deltas --- the tree part will almost always
be pretty small. So if we can transmit the whole tree delta before
spending the time to transmit the text delta, we can detect conflicts
more quickly.
Since Greg Stein is turning this all into a series of DAV operations
anyway, I'm not sure how well that's going to turn out --- maybe it's
fine, but maybe DAV wants to do things differently.
> * The envisioned interface svn_txdelta_to_vcdiff() doesn't
> jive with the edit_fns model, which wants to use a push
> model. Maybe Branko has already addressed this in his work.
Probably svn_txdelta_to_vcdiff needs to be flipped around. We've just
been guessing about what the clients of these interfaces will need.
For svn_txdelta_to_vcdiff, I was assuming we'd be transmitting the
VCDIFF, so we've got some `select' call somewhere noticing that a
socket is writeable, and needing more data to send across it --- thus,
a caller-pulls interface. But looking at Apache, replies are
generated using a caller-pushes interface. And now you want a
caller-pushes interface too. So at this point, I think reversing
svn_txdelta_to_vcdiff looks like a good idea.
I think it should become a function that accepts an svn_write_fn_t and
baton, and returns a svn_txdelta_window_handler_t and baton. Does
that sound right?
Received on Sat Oct 21 14:36:09 2006