On Fri, Dec 15, 2000 at 11:48:52AM -0600, Karl Fogel wrote:
> Greg, hmmm... let me ask a possibly indelicate question. :-)
hehe... no such thing.
> 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?
You and Ben made an incorrect assumption :-)
The tree-delta XML DTD != using the delta editor. You can use one without
the other. I just suggested a different XML format; who said I wasn't going
to use the delta editor? :-) :-)
> 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. :-)
It is. I'm just going to construct XML that is more tuned to the actual
problem semantics: reporting versions. The notion of "add/replace" is not
meaningful in this context.
> 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).
Agreed. My intent is to working *within* the Subversion model. The state
reporting does not map to available WebDAV functionality, but there is a
"framework" for it (the REPORT method). So, I'm mapping to REPORT rather
than pushing back on the SVN model.
[ WebDAV does have something close for this, called "baselines", but it
means recording the client state on the server. We don't want that :-) ]
> 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? :-)
Actually, the FS layer doesn't use the editor interface. There is going to
be some glue (in ra_local) when you link them together.
But this point is somewhat moot at the moment... we were talking about the
XML that goes over the wire.
> 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.
Agreed.
> 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...
No mismatch. You guys just assumed that "different XML" meant "not the delta
editor". Tsk tsk. :-) :-)
Cheers,
-g
>
> ?,
> -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.
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006