On Wed, Dec 03, 2003 at 09:09:10AM +0100, Sander Striker wrote:
> 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.
>
> +1.
+1. If a user wants an ra_local commit to run in the background, they
can background it via their shell's job control interface.
>
> [...]
> > > 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.
>
I agree. Performance is acceptable in the most common use-cases.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 3 16:04:53 2003