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

Re: [INTERM PATCH] Issue 571: A+D should be R in update

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-09-13 22:42:44 CEST

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.


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

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.