On Wed, Feb 1, 2012 at 15:10, Branko Čibej <brane_at_apache.org> wrote:
> On 01.02.2012 20:34, Greg Stein wrote:
>> On Wed, Feb 1, 2012 at 07:57, Julian Foad <julianfoad_at_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
Received on 2012-02-01 21:19:08 CET