[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Concerned about Subversion's speed

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2003-08-12 20:39:13 CEST

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
Received on Tue Aug 12 20:40:03 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.