On Wed, 2003-02-12 at 22:27, Greg Stein wrote:
> [ (was Re: SVNSERVE Tests Failing) ... no wonder I missed it :-) ]
Yeah, well, I changed the subject eventually. :)
> On Tue, Feb 11, 2003 at 05:51:05PM -0500, Greg Hudson wrote:
> P5: The editor is in the best position to determine the format of the
> delta output (e.g. svndiff vs. unidiff) based on requirements or
> environmental/cmdline switches or whatever.
That may be true for the erstwhile XML editor, but I'm not sure it's
true in general.
> > S1 variant #1: Keep apply_textdelta but also add apply_fulltext. This
> > would let S1P[2-4] be more elegant, though not more efficient.
> Is the implication here, that all editors support both code paths, and the
> driver chooses?
I didn't describe any schemes where the editor doesn't have to support
both code paths. Editor composition becomes difficult when you give
editors that much leeway.
[Regarding S1 variant #2, where apply_textdelta can return a flag
saying "please use full text":]
> I'm not sure about the "gives up on P4". Couldn't the editor read the
> necessary config to decide what flag value to return?
Hm, or the editors could take a flag on creation which they pass to the
drivers in turn. (That way the configuration could be read by
libsvn_client or whatever.) You're right.
> > Inconsistent with the rest of the editor
> > interface, which uses a push model.
> The notion of inconsistency is a bit of a red herring, I think. There are no
> other streams in the editor interface. We "push" values at the editor in the
> form of arguments, and you could also say that we push streams at the
> editor. Sure, the editor happens to read from the stream, so it can be
> called "pulling" the data, but that isn't inconsistent with anything else in
> the editor.
I think it is very different. For every other part of the editor, we
provide a chunk of information when we have it. Passing an input stream
to apply_text or apply_textdelta means that for file bodies we suddenly
switch gears and have the editor request chunks of information when it
wants them.
> > The ra_svn receiving editor uses a callback to get at base
> > texts from the FS or WC as appropriate. ra_dav uses a callback to get
> > at base texts from the WC for update/switch/diff operations
> I disagree with this part of the solution. Since the base is optional, the
> driver simply passes NULL to the editor.
But we don't have the target stream either; all we have is some diffs we
got from the network. So we need the base text in order to reproduce
the target stream.
> Hmm. I keep thinking that apply_text should have a mime type for the target
> stream to indicate that the stream is a diff rather than a fulltext.
Uh, full stop. No description of apply_text has ever allowed the target
stream to be a diff. Certainly, what Karl started implementing did not
have that property. What you're describing is functionally similar to
S1 variant #1 (possibly combined with variant #3) as I described things.
> Oh: the guys convinced me that "heck, the driver should just rebuild the
> fulltext and pass that in [along with the base] rather than complicating the
> interface with a possibly-diff/possibly-full stream argument." And now we
> see the results of that: the driver may have to reach into some other system
> to fetch the base, when it doesn't necessarily have it. Thus, it is best to
> allow for diffs to flow through the system. If somebody *wants* a full text,
> then assume they have access to the base.
> [ and that assumption holds water in all of our cases right now ]
I'm not sure what this means.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 13 04:47:38 2003