Greg, hmmm... let me ask a possibly indelicate question. :-)
Are you against using the delta editor mechanism to report working
copy state because you feel that mechanism is inherently
inappropriate, or because it doesn't map well to the DAV protocol?
If the former, I confess that my instincts run completely the other
way: it's hard for me to imagine a *more* appropriate mechanism. I
mean, the working copy has to report its state precisely because that
state differs from a given pristine version tree (otherwise, it'd just
report a version number and be done with it). And what's a good
mechanism for streamily reporting a delta against a base tree, even a
delta that consists entirely of ancestry differences? Sounds like
`svn_delta_edit_fns_t' to me. :-)
But if the latter, hmmm, I'm not sure what to say, then. I think we
all agree that the network layer's semantics shouldn't perturb the
rest of Subversion (at least, that was one of the assumptions we
started out with). Imagine that the working copy and repository fs
layer were linked directly together, same memory space and all that:
in that case, there can be little doubt that the best way for them to
talk to each other would be by swapping editors, each driving the
other's. It's just so natural -- how could anything that feels so
good be wrong? :-)
The network layer shouldn't change this model, it should just make it
happen over the wire, when the memory spaces aren't shared. In fact,
we've always assumed that working copies and repositories don't even
*know* whether a given transaction is happening over a network or
locally. If DAV semantics start flowing down into those libraries,
there'll be no end of trouble, I think.
So if the problem is a paradigm mismatch between DAV and
svn_delta_edit_fns_t, let's talk about it in those terms and see if
there isn't some way to make it work...
?,
-K
Ben Collins-Sussman <sussman@newton.collab.net> writes:
> Greg Stein <gstein@lyra.org> writes:
>
> > The body isn't a "tree delta" and pretending it is some variant does
> > a disservice. The body is simply reporting local state, not a
> > difference.
>
> You sound like Karl, about 4 months ago. :)
>
> Why are "reporting local state" and "tree diff" mutually exclusive
> concepts? The idea here is that one can express a working copy's
> state *as* a difference against some pristine tree. Just because
> we're omitting text-deltas doesn't mean it's still not a legitmate
> tree-delta. There's no dishonest twisting of semantics going on.
>
> The reason why we liked this idea is that it allows us to use the
> existing "editor" interface, rather than coming up with a whole new
> system of describing a working copy.
>
> Also: it's more efficient than explicitly listing each and every
> revision number in the working copy. If a working-copy resource is
> the same revision number as the root dir, we don't report it at all.
Received on Sat Oct 21 14:36:17 2006