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

Re: [PATCH] Re: "svn revert" performance

From: Gareth McCaughan <gareth.mccaughan_at_pobox.com>
Date: 2003-11-01 12:37:19 CET

On Saturday 01 November 2003 4:00 am, Garrett Rooney wrote:

> > 2. The function presently called svn_client_revert_list
> > doesn't report nonexistent-path errors. (Maybe it should
> > do, but the only caller is the commandline client, which
> > ignores them.) It feels wrong to expose *no* version of
> > "revert" that just reports an error when a path doesn't
> > exist.
>
> As Philip said, that could be taken care of by the notification
> callback.

Well, sort of. The notification callback doesn't get to report
any information back to its caller, so the trouble can be
reported but the information can't be used to stop the
reversion. (Well ... you could cheat and have the notification
callback set a variable that the cancel callback checks.
But that's ludicrous.)

Anyway... my feelings on this are not strong, and it seems
as if the general preference is for having only the one function
in the API. If I haven't heard any dissenting voices in, say,
a day's time then I'll send in a version of the patch that
has only one function. (Called svn_client_revert, of course.)

I forgot to mention: all the tests pass with the patch applied.
This is interesting because there *is* an externally visible
change: without --quiet, the way in which nonexistent paths
are reported is a bit different from before. I'm guessing that
this isn't a problem.

Before:
    svn: warning: svn_wc_is_wc_root: '<name>' is not a versioned resource

After:
    Skipped missing target: <name>

-- 
g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 1 12:38:07 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.