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

Re: permanent solution for deltification problem (issue #1601)

From: Sander Striker <striker_at_apache.org>
Date: 2003-12-03 09:09:10 CET

On Wed, 2003-12-03 at 02:56, kfogel@collab.net wrote:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > If mod_dav_svn wants to tell the client the commit has succeeded before
> > doing deltification, that's fine. It's a server process, and it's
> > allowed to do processing that isn't part of a client request-response
> > cycle. svnserve in daemon mode could do the same. No forking
> > required. (If the vagaries of Apache demand forking to make that
> > happen, then fine, but the fork belongs in mod_dav_svn then, not in
> > libsvn_fs.)
> Hmmm. You know, I'd be okay with that -- the truly independent
> servers inform the client that the commit is done and then deltify,
> while the "non-independent" server processes just deltify in-process.


> > If we have a performance problem, the solution is to make our
> > performance better. Hiding the problem by making a chunk of the
> > operation take place in the background is a cheesy workaround, not a
> > solution.
> Making deltification faster would be better, sure! How can we do it?
> I don't know a way, but then again, haven't had time to explore the
> issue in depth.

It means going through the code with a fine toothed comb, probably
replacing generic datastructures with dedicated datastructures, shaving
cycles where possible. As it is, the libsvn_delta code isn't the
easiest piece of code to grok, making this more than a small
undertaking. I would personally suggest that we don't mess with it so
close to 1.0.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 3 09:09:48 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.