tree copies can be O(N) when copyfrom args not used

Mike's email says it all:

From: cmpilato@collab.net
Subject: Re: cheap copies
To: Ben Collins-Sussman <sussman@collab.net>
Cc: SVN Dev List <dev@subversion.tigris.org>
Date: 08 Nov 2002 18:04:55 -0600                                     
          

Ben Collins-Sussman <sussman@collab.net> writes:

> Whenever we make a branch or tag (svn cp URL URL), it seems to take a
> disconcertingly long time for the commit to finish.  I mean, it takes
> *noticeably* longer than when I simply commit a few file
> changes... like 10 seconds instead of 2 or 3.
>
> Something seems to be interfering with our magic O(1) copies.
>
> Maybe it's something within libsvn_fs, like walking the tree to make
> every node immutable?

Every node?  It walks the FROM_PATH read-only, then walks the TO_PATH
making things mutable (between '/' and TO_PATH's parent).

> Maybe the post-commit-hook script is doing a full tree walk to
> discover it's a copy?

Uh...no.  We background our post-commit hook.

> There's an O(N) thing happening somewhere, and I'm about a hair away
> from filing an issue.

Are you sure it's O(N)?  Have you copied anything other than /trunk to
verify this?

A-ha.  I found the culprit (4 minutes to debug...it's *goooooood* to
know the filesystem code).

mod_dav_svn's MERGE response handle doesn't use the USE_COPYFROM_ARGS
flag to svn_repos_dir_delta().  Which means that dir_delta is sending
an ADD for every single file and dir in the copied tree (despite the
fact that client doesn't give a rip, and will immediately discard this
info as rubbish on a repos-to-repos copy operation).

All we need now is a fix.