Re: Concerned about Subversion's speed

kfogel@collab.net writes:

>> This is good news. However, I would expect that after 'svn up', the
>> 'status' processing time should go back down to the same as for the
>> freshly-checked-out dir -- but it does NOT: it stays high. I should
>> think that could be fixed...
>
> You know, I think this might be
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=791

I have a patch that does something like that.

It's not been committed because it had a few kinks. One problem is how
to trigger the repair process. To modify the working copy a write
lock is required, so 'svn status' can't really do it. Oddly 'svn up'
didn't appear to trigger it either, only things like 'svn commit' and
'svn revert' would effect the repair. Also, I think the user should
be able to repair the working copy without otherwise modifying it,
which means that even if 'svn up' did the job, some harmless command
would need to do it as well. I experimented with adding some code to
'svn cleanup' to do the job.

The prop-time was another problem, my patch repaired that as well, but
I wasn't sure what should happen. While the text-time can get out of
date due to perfectly "legitimate" user actions, that doesn't apply to
prop-time since the properties can only be modified by Subversion. I
wasn't sure if silently repairing prop-time was a good idea.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org