[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: <kfogel_at_collab.net>
Date: 2003-12-03 02:56:32 CET

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.
That could work.

By the way, there's a constraint going on here that I should probably
make explicit: the other Chicago developers and I are in meetings most
of every day for the rest of this week. That, combined with the fact
that this issue clearly needs some more discussion, means #1601 is
probably not going to get resolved this week. That's fine, I just
thought I should say it out loud, if only to explain why I was
formerly so gung-ho about solving this immediately, yet now appear to
be slacking off :-). Every email is squeezed in between meetings.

Still need to set a 0.35 date, will do as soon as can.

> 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.

Wish I had time to write more right now :-(, but anyway, maybe the
idea of differentiating between {mod_dav_svn,daemon_ra_svn} and other
access methods would lead to something everyone can like.


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