On Wed, Feb 1, 2012 at 15:10, Branko Čibej <br...@apache.org> wrote: > On 01.02.2012 20:34, Greg Stein wrote: >> On Wed, Feb 1, 2012 at 07:57, Julian Foad <julianf...@btopenworld.com> wrote: >>> Greg Stein wrote: >>> >>>> Oh. And that is an interesting point. We need server-side processing >>>> of a commit plan. Maybe the plan code goes down into libsvn_subr so >>>> both sides can create/consume/process the plans. [...] >>> That's what libsvn_delta's for, no? >> Oh. Yeah, I guess it could go in there, where libsvn_delta is "diff >> code, and describing and making changes to trees". Something like >> that. And a commit plan falls into that. > > I thought libsvn_delta was strictly contextless binary deltas ... xdelta > reimplemented, more or less. We even have a separate libsvn_diff. > > Clearly libsvn_subr is a catch-all, but tree walking code hardly fits in > there. > > If the delta editors are currently client-side, and we suddenly need > server-side code, too ... maybe a new library is in order?
The basic code for svn_delta_editor_t is in libsvn_delta. eg. default_editor, cancellation editor, etc. Plus svndiff and xdelta. Some other bits, probably. We use the delta editor in libsvn_repos (the dir_deltas stuff). The editor drive is then marshalled into (eg.) the update report response. IOW, libsvn_delta is already used on both client and server. (forgot about libsvn_diff) Cheers, -g
