On Wed, Feb 28, 2001 at 10:18:00PM -0500, Greg Hudson wrote:
> > Jim pointed out that I won't be the last person who wants to do
> > this, so I thought the prototype above would be a good general
> > solution: convert an svn_string_t into a txdelta_stream.
>
> Given our current machinery, what you would prototype would look
> something like:
>
> svn_error_t *apply_string_as_delta (svn_string_t *string
> svn_txdelta_window_handler_t *handler,
> void *baton);
>
> which would do the pushing itself, and then you'd pass the handler and
> baton you got from apply_textdelta to that routine.
>
> (You'd have to pick a better function name, though. A pool argument
> might be necessary, but I don't think so, since you'd just be
> constructing a single window and you could use stack storage for it.)
It might be necessary to pass a pool.
I have a function almost exactly like the above in libsvn_ra_dav/fetch.c.
Take a look at fetch_file_reader(). It happens to have a baton that carries
the "handler" and "baton" that GregH quoted above, but passing those
explicitly is easy. Then, it takes a buffer/length pair and applies that.
Inside, it constructs all the right doo-dads and calls the txdelta handler.
Note that a pool is referenced in the svn_txdelta_window_t structure. I
might argue that it shouldn't be there (since the handler/baton can always
create/destroy a subpool for temp allocations). I also happen to place a
pool into an svn_string_t, but that shouldn't be needed, as the string is
(theoretically) constant.
> > Instead, what if we had a func that converted an svn_string_t into a
> > *single* window containing a solitary `new' op? Then I could push
> > the one window, then push a NULL, and be done.
>
> This would also be fine.
I'd prefer the construct-on-stack approach. There isn't a lot of reason to
create windows on the heap.
To the original question, I'd prefer to not deal with txdeltas and windows
and stuff. I want to give the FS a stream and a MIME type for that stream.
Let the FS sort out (based on content-type) whether to use txdelta or just
to drop the plain text into the node.
The one gotcha that I have is the possibility for replacing portions of a
file. e.g. "place these 10 bytes in positions 53..62." The overall size
won't grow (unless they write at the end of the file), this would just be
patching (multiple) byte ranges. While this doesn't seem too bad, it gets a
bit uglier when you consider the byte ranges may arrive in arbitrary order
(i.e. we cannot guarantee that range2 is positioned after range1).
So... the ideal interface for me can handle three forms of changing file
contents:
1) I feed it an entire plain text file in chunks (basically, I get a
writable svn_stream_t and drop data in)
2) I feed it an entire SVNDIFF in chunks (I'd write to an svn_stream and
something between the stream and the FS would interpret the SVNDIFF)
3) I feed it arbitrary ranges of plain text, with each range provided in
chunks (sort of a seek-write-write, seek-write pattern).
The current txdelta interface in the FS supports this, I think, but there
would be a good chunk of code on my side for handling (2). For option (3), I
could construct windows that patch ranges. I seem to recall that delta
windows can only occur sequentially, so handling (3) may involve multiple
applications of a delta ("open. patch range 1. close. open. patch range 2").
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:23 2006