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

Re: CVS update: subversion/subversion/include svn_delta.h

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-10-02 22:29:26 CEST

Okay, here are some better thought-out responses, Greg.

Greg Hudson <ghudson@MIT.EDU> writes:
> The current interface does not enforce that directory batons are used
> in depth-first order; that is only enforced through documentation. It
> would be easy to enforce depth-first order by doing away with
> dir_batons and storing the current directory stack inside the
> editor_baton.

As Jim said in an earlier post, this is technically possible, but it
makes the interface more "brittle" (i.e., the call sequence had better
be correct, because an bad call would be hard to detect early).

Although it's really only an intuition, I'd like to stick with the
current baton arrangement. It does not enforce depth-firstness, but
it's okay to rely on the documentation and social pressure to do that
:-)... And who knows, we may someday find that there _are_ situations
in which depth-first is not the only way to go (although that'd be
hard to believe for XML generation, of course).

For now, let's document that calls happen depth-first, but retain a
baton structure that does not bind us to that. It's easy to firm up
the baton restrictions later, when we have a better idea of what
assumptions always hold true. I feel like changing the batons now
would be premature.

> The current interface does not enforce that apply_delta calls only
> come just after a file is opened or after the root baton is closed.
> This is harder to enforce through the interface, but it would be
> possible to come closer by eliminating file_batons and having the
> producer make an explicit call when a text delta is to be deferred.

Actually, the only requirement right now is that apply_delta calls
happen while the file is open -- that is, between a file_open and
file_close call, so that the file's baton is active.

It's true that the interface does not prevent the caller from
retaining a file baton pointer longer than appropriate, and passing it
as an argument when it's no longer valid... but the same could be true
of any baton. As long as the documentation makes clear the exact
baton lifetimes, well-behaved callers should be okay.
Received on Sat Oct 21 14:36:09 2006

This is an archived mail posted to the Subversion Dev mailing list.