Sure... I'd imagine those input variants would be handled by common routines
in libsvn_delta. Whatever is on the "bottom" side of those would be handled
by the FS.
Cheers,
-g
On Thu, Mar 01, 2001 at 11:15:27AM -0500, Jim Blandy wrote:
>
> Greg Stein <gstein@lyra.org> writes:
> > 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.
>
> We've discussed a similar situation before. I don't think the FS
> should deal with MIME types. It all needs to be put in a canonical
> form at some point, and I'm quite sure that point should be *outside*
> the filesystem interface. I have no problem adding any number of more
> specific text editing functions to the FS interface, but dealing with
> MIME issues is *not* part of the FS's contract.
>
> > 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).
>
> I'm happy to add whatever functions you'd find helpful, as long as
> they've got a specific, well-defined behavior, and there's some reason
> it's beneficial for them to be inside the FS, instead of outside the
> FS and using some more generic interface to do their work.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:24 2006