[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Change #6: Move textdeltas to the "other side" of the editor.

From: Ben Collins-Sussman <sussman_at_newton.collab.net>
Date: 2001-01-20 03:38:19 CET

Change #6: Move textdeltas to the "other side" of the editor.

Status Quo:

   The driver of an editor takes a source and target stream, puts them
   together via svn_txdelta() to produce a stream of "windows". The
   driver then pushes these windows at the editor's window-handler.

Proposed Change:

   Move this process to the other side of the interface, into the
   editor implementation, giving the editor the power to deal with the
   source and target streams directly.

             - remove the editor's apply_txdelta() routine
             - create two new routines:

                apply_delta (filebaton, [src_stream], target_stream)
                set_file_contents (filebaton, [src_stream], delta,
                                   enum delta_type)

                apply_delta() sends svndiff deltas.
                set_file_contents() can send plain text or other

             It becomes the obligation of the editor implementation to
             implement at least one of these two routines; if one
             routine is NULL, the driver must use the other.


   It's too restrictive to force every editor implementation to accept
   and deal with small svndiff windows. For example: Greg Stein wants
   to send plain text while debugging his commit-editor and network
   layer. It's best to allow the RA layer to make it's own choice
   about how to break up the two streams most efficiently.

   The reason [src_stream] is optional is that it may be NULL; this
   presumably means that the editor already has access to the src

   (Greg and Jim, did I get this explanation totally wrong? My notes
   here aren't perfectly clear. Please elaborate if you need to.)
Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.