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

Re: 404 error for each newly added file

From: <kmradke_at_rockwellcollins.com>
Date: Thu, 29 Oct 2009 17:59:49 -0500

sussman_at_gmail.com wrote on 10/29/2009 04:11:21 PM:

> It's probably just the logic in the ra_dav or ra_serf client network
> module, enforcing proper webdav (and svn?) semantics. Every path
> modified/deleted/added in a commit is a whole separate request. For
> 'adds', the client is likely doing an existence check: does the path
> already exist? If so, fail the commit (the client is out of date).
> Most of the time the answer is "404", i.e. "no, it doesn't exist, so
> go ahead and PUT the file".) If this existence check didn't happen,
> then there's a risk of the PUT simply overwriting an existing object.
> Honestly, though: if you're worried about svn's performance over
> HTTP, stop using HTTP. It's a lost battle. HTTP is stateless, slow,
> and WebDAV is really complicated. We already rewrote it to use 30%
> fewer requests earlier this year, and I doubt it can get much leaner.
> If you want speed, you'll get an order-of-magnitude speedup by
> switching to svn:// instead of http://.

In my testing, I've seen very little (if any) performance difference
between svn:// and http://... (Both wan and lan links, both large
and small transactions). Possibly I'm doing something wrong, or
possibly it is an artifact of our network topology. I was even
giving svnserve an advantage by not using any authentication in
my tests...

Until recently, the lack of logging in svnserve was a show stopper.
I'd also need to get kerberos authentication setup with
both windows and solaris servers under svnserve. Might be
a real challenge on the windows server.

I'd gladly move to svn:// (or at least support both) if I can
find raw data to validate the performance claims.

Kevin R.

Received on 2009-10-30 00:00:06 CET

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.