ra_dav repositories have extremely slow logs for large revisions (was Re: Very slow log)

[Chris Rose <ch...@messagingdirect.com>]

Although I no longer need assistance with this, I figured I'd post  
here my analysis of the issue and my solution, for future users.

Initial conditions:

A revision (in this case revision #106204) in an fsfs repository.
- the revision touches 9300 files (not 50,000 as previously reported;  
don't ask me how that number came up)
- the revision is exclusively propdel and propset operations on said  
files
- on disk, in the db/revs directory, revision 106204 is 6.15Mb

The behaviour with svn log:
# time svn log --limit=1 -r106204 https://svnhost/trunk/file_in_revision
real    	5m2.648s
user    	0m0.049s
sys    	0m0.004s

# time svn log --limit=1 -r106204 svn+ssh://svnhost/trunk/ 
file_in_revision
real    	0m0.632s
user    	0m0.014s
sys     	0m0.010s

# time svn log --limit=1 -r106204 file:///repos-path/trunk/file_in_revision
real 	0m0.285s
user	0m0.019s
sys  	0m0.025s

Using wireshark I determined that this was not a network issue; the  
repository does not send any more data (modulo differences in  
protocol) for DAV.  Certainly not enough more to justify the difference.

So, if you have revisions like this and your performance sucks,  
consider losing ra_dav and moving to svn+ssh

(Guys, should I submit a bug?  Reproducing this requires a large and  
wide-spread repository, but I suppose it should be possible to  
generate one for an isolated test case)

On 27-Feb-08, at 10:39 AM, Chris Rose wrote:

> I should clarify:  What I want to do out of this is to edit <repo>/ 
> db/revs/106204 and change it from a 6.5-mb revision with 40,000  
> files touched to a revision that does... nothing.
>
> This is, I think, problematic, because there's probably a few files  
> that are children of this revision.  However, it's plausible at this  
> point to fix it by hand.
>
> What I _really_ want is svn obliterate :)
>
> Chris Rose wrote:
>> I have a revision in my repository where around 50,000 files were  
>> modified (it was a global property change to clean up a pervasive  
>> import issue, if you're wondering).
>> This makes svn log take for-freakin'-ever on any file that was  
>> involved in this change if the log message passes through this  
>> revision.  Is there any way at all to make this go faster?  Or  
>> to ... I don't know, remove the revision from the output of log?   
>> It's all but a no-op, I only made the change for cosmetic purposes  
>> -- the property name had a typo, but wasn't mission-critical -- so  
>> this is especially galling.
>
> -- 
> Chris Rose
> Developer    Planet Consulting Group
> (780) 577-8433
> crose@planetci.com
>

-- 
Chris Rose
Developer    Planet Consulting Group
(780) 577-8433
crose@planetci.com