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

Re: [PATCH] Speed up svn:externals updates by using an internal "svn switch" rather than a straight delete.

From: Ross Mark <rossm_at_controllingedge.com.au>
Date: 2005-01-04 22:56:17 CET

Philip Martin wrote:

>Ross Mark <rossm@controllingedge.com.au> writes:
>
>I like the basic idea. Have you run the regression tests with this
>patch applied?
>
>

I'm running them now. Normally I interrupted the regression test once
the externals_test had be run.

>
>
>>+ /* Try doing a switch first */
>>+ err = svn_client_switch (NULL,
>>+ path,
>>+ new_item->url,
>>+ &(new_item->revision),
>>+ TRUE,
>>+ ib->ctx,
>>+ ib->pool);
>>+ if (err)
>>+ {
>>+ /* The switch failed so do a cleanup and delete the old*/
>>+ svn_error_clear (err);
>>+ err = svn_client_cleanup(path, ib->ctx, ib->pool);
>>
>>
>
>What's the reason for calling svn_client_cleanup? Given that cleanup
>will steal WC locks it's probably not the right thing to do.
>
>
>
The problem is, if the new url for the externals entry points to a
different repository the attempted switch obtains the locks then bails
out leaving the locks once it realise that the repositories are
different. This is the one part of the process that I didn't like and am
happy to take any suggestions.

>>+ if (err)
>>+ svn_error_clear(err);
>>
>>
>
>Hmm, that ignores all errors, is that the right thing to do or should
>it only be certain specific errors? I suppose one could argue that
>the original code would always do the relegate/checkout stuff and so
>all errors is OK. I'm not sure what's best here.
>
>
>
I took the attitude that the original code just deleted everything so
the end result is the same.

Ross

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 23:03:20 2005

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.