"Peter N. Lundblad" <peter@famlundblad.se> writes:
> On Tue, 13 Sep 2005, Philip Martin wrote:
>
>> Christopher Ness <chris@nesser.org> writes:
>>
>> Such a change may well contravene Subversion's ABI compatability
>> guidelines; it's likely to break existing notification callbacks. I
>> see that we added locking values to svn_wc_notify_action_t in 1.2, but
>> that didn't break things in quite the same way. A 1.1 client using
>> 1.2 libraries would continue to work so long as no locks were
>> involved, whereas your proposed change is likely to break 1.2 clients
>> using 1.3 libraries. You may need to rev the notification API.
>>
>>
> Ouch! NOt again, please! I think you're a bit extreme when you claim that
> we break ABI by just adding an enumeration value (OK, in a very strict
> sense, but we're a library, not a standards body:-). But in this case,
> when you *replace* some values with a new value, we would break ABI in a
> way that isn't acceptable.
Perhaps my point wasn't clear.
Adding the enum value does not break the ABI, it's the rest of the
patch that does that: when it stops sending 'D'+'A' and sends the
newly introduced 'R' instead. The patch modifies the svn client to
cope, but obviously third-party clients will still get broken.
To be acceptable the patch needs to provide an interface that causes
unmodified clients to continue to receive 'D'+'A' while allowing more
up to date clients to receive 'R'. That probably means new fields in
svn_client_ctx_t.
> But, why can't this stuff be kept in the CLI
> code. We could leave it up to each notifier implementation to coelsce D/A
> into R.
That would be another way to do it, although it would mean every
individual client has to implement it separately.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 13 22:24:20 2005