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.
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
- 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
# time svn log --limit=1 -r106204 svn+ssh://svnhost/trunk/
# time svn log --limit=1 -r106204 file:///repos-path/trunk/file_in_revision
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
Developer Planet Consulting Group
Received on 2008-02-28 07:20:24 CET