subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <>
Subject branching over mod_dav 2.4.6 is O(tree) (was: Re: Branching slow 1.8.11 https)
Date Wed, 01 Apr 2015 10:28:18 GMT
[ moving to dev@, please remove users@ from replies ]

Johan Corveleyn wrote on Sun, Mar 29, 2015 at 19:57:34 +0200:
> On Sat, Mar 28, 2015 at 5:09 PM, Bert Huijben <> wrote:
> > Httpd's mod_dav was updated in some recent version to do a full lock
> > traversal on copies and moves. I think we already applied some
> > optimizations, but the real fix would be that mod_dav shouldn't do
> > this work (which our repos layer already does).
> >
> > I'm not sure which release we applied the first set of optimizations.
> >
> Thanks for refreshing my memory.
> So the problem is known as issue #4531 (server-side copy (over dav)
> uses too much memory) [1]. The memory usage issue has been fixed in
> SVN 1.8.11 and 1.7.19 (see CHANGES), but a performance problem remains
> (copy is no longer O(1), but depends on the size of the tree being
> copied). That's a direct violation of one of Subversion's "old selling
> points" vs. CVS: that branching / tagging is O(1). Branching / tagging
> taking several minutes brings back "fond memories" from CVS' days.
> As Philip pointed out in his last comment on #4531 [2]: "This issue is
> related to a change in mod_dav in 2.2.25 to fix PR54610 which
> added a walk over the copy source looking for lock tokens." (also
> released in 2.4.5; so both httpd 2.2.25+ and 2.4.5+ are affected --
> older httpd's won't have this problem I guess).
> Again quoting Philip: "Apache knows in advance that the walk is
> redundant in cases such as Subversion's URL-to-URL copy but Subversion
> cannot avoid the read access. We should attempt to fix mod_dav to
> avoid the walk where possible."
> So my hope rests with Philip and others who might have the necessary
> knowledge to fix this in mod_dav. It's really not acceptable that
> branching / tagging (or I'm guessing also: moving a large tree with a
> server-side move) takes several minutes.

So, what will a mod_dav fix look like?  I understand the issue is that
it walks the copy source for locks.  Should it stop doing that?  Should
it allow the backend module (mod_dav_svn / mod_dav_fs) to implement the
walk in a more efficient manner — for example, adding a "Are there any
locks under path X" hook that the backend module could implement?

(Rather than the current design, which AIUI is the backend walks the
tree and mod_dav calls "Is path X locked" for each path reported by the


View raw message