On Tue, 13 Sep 2005, Philip Martin wrote:
> "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.
>
Yes, it was celar to me. What I meant was that adding (and using) new enum
values shouldn't be a problem in practice (like we did for locking). IN
this case, we are stopping to use some values as you point out below.
That's when it becomes a problem in practice.
> > 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.
>
Yes, but is that a big problem? Yes, when I think about it, I see that
the client would have to keep the list of deleted items until the end of
the whole operation, which is not nice.
I wanted to avoid revving the notification API again, since it touches a
lot of places. Maybe there is some other way around this.
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 13 23:13:17 2005