I like the format you proposed for the non-hierarchical text deltas
--- it's a pretty straightforward transcription of a series of calls
to an editor, and it's clear that it can handle anything somebody
throws at an editor, even an unconstrained editor.
He's also made pretty clear why, even when we constrain the ordering
of calls to the edit functions, it's still annoying to generate a
hierarchical XML structure. In a word, you can't really tell when to
close something until you've been asked to open something else. So
half the code for generating any particular structure ends up smeared
around in other, apparently irrelevant functions. There's no simple
correspondence between the editor consumer function and the XML it
needs to generate.
And, at the moment, all our consumers can pretty much handle
random-access tree tweaking. (I've changed the filesystem interface
to make it even more so.)
All that said, I still think it's worthwhile generating some
hierarchical form of deltas. The hierarchical form has a bunch of
nice properties that tell you a lot about what's going on in the tree.
The fact that every edit *can* be expressed hierarchically is very
interesting.
*right*. Anything you could do with the usual Unix filesystem,
Subversion was supposed to be able to handle. It's easy to pick
specific cases and invent something that handles them, but you haven't
done your job until you've proven that you can handle any possible
rearrangement.
Designing the tree delta format was what convinced me that I could
actually make those guarantees. It helped me characterize all
possible tree rearrangements in a way that convinced me I could handle
them. I think Karl and Ben would say that the hierarchical format ---
or, more precisely, knowing that the the hierarchical format is
sufficient --- has really helped them in designing their modules.
Those are all pretty fuzzy arguments. "Well, now we all know it can
be done --- glad to hear you've persuaded yourself. So, what's the
best textual format for deltas?"
I'm not wedded to any particular syntax, but I do think a hierarchical
form is a good thing.
- It provides a restricted form for tree deltas that is easier to
reason about than the less restricted forms. I do think that we
will eventually care about this.
- While none of our consumers require hierarchy at the moment, they don't
mind it, either.
- While none of our producers require hierarchy at the moment, they
don't mind it, either.
So I don't think hierarchy really limits our ability to plug arbitrary
consumers and producers together. The case to watch out for is a
consumer that can't easily produce hierarchical changes --- is mod_dav
such a case?
As far as your troubles generating the hierarchical delta are
concerned, I think we should tweak the svn_delta_edit_fns_t
requirements to maximize what you can confidently write at each step.
I think this, not hierarchy, is the real source of your troubles.
For example:
- we could require that directory property changes come at
a certain time, so they won't occur within something else.
- We could require that postfix text deltas be generated with a separate
function, other than apply_textdelta.
I don't think the kinds of guarantees you need to easily generate a
hierarchical delta are very different from the sorts of nice
properties I referred to above, so serving the hierarchical delta
generator is probably good in the long run too.
If I can persuade you to stick with the hierarchical form, feel free
to add what restrictions you need to the editing functions.
Received on Sat Oct 21 14:36:10 2006