> But the file's contents didn't necessarily change; maybe only the
> properties changed. So you don't know whether a text-delta is coming
> later or not.
The delayed text deltas are Karl and Ben's thing, but if they don't
provide a way to delay file property deltas, that sounds like an
oversight. It seems to me that the delta producer should be able to
send property changes and text changes at any time.
> * Although the producer of edit_fns calls is restricted to a
> single traversal of the tree, it doesn't have to be
> depth-first. But XML delta output is hierarchical; how can
> you stop and go back to a directory later if the producer
> doesn't give you calls in depth-first order?
We've changed this, explicitly for the benefit of the XML generator.
The new rules in svn_delta.h are:
- The producer may call `replace_directory', `add_directory',
`replace_file', `add_file', or `delete' at most once on any given
directory entry.
- The producer may not close a directory baton until it has
closed all batons for its subdirectories.
What these rules add up to is that you, the producer, need to use
directory batons as if you were doing a single traversal of the
tree. You go in only once, and you finish all your
subdirectories before you leave.
Note that the `close' rule does *not* apply to file batons: you
don't need to close a file baton before closing its parent
directory's baton. You can keep as many file batons alive for as
long as you like, and call `apply_textdelta' or
`change_file_prop' on them any time you please.
These restrictions make it easier to write a consumer that
generates an XML-style tree delta. An XML tree delta mentions
each directory once, and includes all the changes to that
directory within the <directory> element. However, it does allow
text deltas to appear at the end. */
Received on Sat Oct 21 14:36:09 2006