[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVNSERVE Tests Failing

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-02-02 21:52:53 CET

On Sat, 2003-02-01 at 20:24, Karl Fogel wrote:
> Yah. It wasn't just that, it was also that it made it easy to not
> deltify for new imports (which we formerly had to do).

If, for speed reasons, we want to send full texts of new files
(sacrificing the bandwidth benefit of self-compressed deltas), we can do
that without modifying the apply_textdelta interface. The sender just
has to make up fake delta windows. Each window contains one
instruction, saying, "insert this large block of new data." These fake
deltas would have minimal time and negligible space overhead.

The same technique can be used to avoid deltifying over ra_svn, only the
driver needs to have some way to know that the consumer doesn't want
real deltas. (Not as elegant as the current apply_text, where the
consumer just has to omit the deletification code.) We could do that
with a function or flag in the editor interface (a function would give
us the flexibility of asking "do you want deltas" over the network; a
flag would be simpler; I'm not sure whether we would want the
functionality).

There may be more elegant solutions which don't break the
connecting-pipe property, but this should certainly be considered as
part of the solution space.

> It also
> changes the interface from driver-push (pushing to window handlers,
> that is) to editor-pull, although that could probably be accomplished
> without changing the input type.

Right; changing the direction and changing the stream types are
orthogonal.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 2 21:53:45 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.