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

Greg Hudson <ghudson@MIT.EDU> writes:

> > (Clearly, there might be other ways to arrange all this; I'm not
> > trying to convince you to change your tastes or anything. But I
> > think the interface does in fact have the properties you say you
> > want.)
>
> So, here is a possibly better description of the issues I have:
>
> 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.

Certainly. By using the sequence of calls to specify the directory or
file to operate on, we could have the interface constrain the sequence
of calls nicely. So if we called:

  replace_subdirectory ("foo")
  replace_subdirectory ("bar")

     here we're editing foo/bar

  close_subdirectory () ; perhaps this should be renamed

     here we're editing foo again

  replace_subdirectory ("baz")

     here we're editing foo/baz

  replace_file ("x")
  apply_textdelta (DELTA)

     this applies DELTA to foo/bar/x, even though the arguments to
     apply_textdelta give no indication whatsoever of what file it's
     supposed to operate on

Problem is, this change makes the interface somewhat brittle. If some
bug causes me to omit a close_subdirectory, then there's no way for
the consumer to figure this out. In the above example, it'd happily
descend into foo/bar/baz, and everything from that point on would be
wrong. Even if we require a depth-first ordering, the batons give
enough information for the consumer to verify that the producer is
saying something coherent.

Certainly, the presence of file/directory batons at all adds
complexity, which engenders mistakes. But they give us enough
information to catch a lot of problems.

So I agree with your point; I'm just not sure if it's the most robust
design.
Received on Sat Oct 21 14:36:09 2006