The 'dumpstream' parser isn't quite done. I've got a push-pull problem.
So we have this parser reading a dumpstream and driving a vtable.
Currently, we have one vtable implementation which commits new
revisions to a repository.
When the parser encounters new fulltext for a file, it calls a vtable
callback (set_fulltext), which is supposed to provide a writable
svn_stream_t that the parser can "push" the fulltext at. (If the
vtable doesn't want any text, it can return a NULL stream instead.)
So now I'm implementing this set_fulltext callback. The problem is
that the only way to set/change a file's contents is with
svn_fs_apply_textdelta. This function also returns a stream that you
can 'push' txdelta windows at.
So how do we generate txdelta windows? We have a single diffing
algorithm for that: svn_txdelta(). The function takes two
svn_stream_t's, "pulls" data from them, and emits windows that you can
then "push" at the filesystem.
Confused yet? :-)
The problem in a nutshell, then, is that the vtable callback is having
data "pushed" at it by the parser, but the only way to move this data
into the filesystem is via a mechanism that wants to "pull" data.
I can't just set up some funky pipe whereby someone is pushing data at
one end, and someone else is pulling data at the other end. There's a
fundamental conflict in flow-control there, unless I fork a child
process. :-)
So what are some possible solutions?
1. Have the callback implement a stream which accepts all incoming
data into a tmp file. When the parser closes the stream, allow
the fs to pull the data from the tmpfile. ugh.
2. Change the callback prototype, so that it pulls data from a parser
stream. If a vtable didn't want any text, it would immediately
close the stream, and the parser would just skip-over any
remaining textdata (as it does now, when the vtable isn't
interested.)
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 11 16:44:40 2002