Karl wrote:
> Huh, that seems wrong. We ought to sleep once at the end of the
> overall operation, whether or not there were multiple targets.
...
> > So it would seem that the best way to get the behavior you want is to
> > passing the whole target array to the core libraries and iterated over
> > them there instead of in the client program itself. I'm fine with
> > such an API change. Got patch?
>
> That would fix it, yep.
A first pass at a patch is attached (rather than included,
because I have reason to suspect that my MUA sometimes
wraps lines: sorry). Things I'm not entirely happy about:
1. The new svn_client_revert_list function never returns
an error when an entry doesn't exist. That's the behaviour
svn_cl__revert (currently its only caller) wants, but it's
not necessarily what every imaginable caller would want.
Should there be another flag passed in to determine
whether nonexistent entries should be treated just like
other errors?
2. The old svn_cl__revert used to call svn_cl__check_cancel
after each individual reversion. It's not so easy to do that
down in the depths, and in any case there's less need now
that we aren't sleeping for 1s per reverted path. But, still,
it makes me uneasy not to have the check there at all for
an operation that can in principle take an unbounded amount
of time. Should there be a callback or something?
3. Is "svn_client_revert_list" the best name for the new function?
Is it right for both this and the old function that reverts a single
path to continue to exist? (I think the answer to the latter question
is "yes", but am open to persuasion.)
And, as an aside, something puzzles me looking at svn_cl__revert:
it calls svn_cl__get_notifier, but doesn't seem to do anything with
the results. Does svn_cl__get_notifier have some important side
effect? (If so, it should surely be documented.) If not, it looks to me
as if that call can just go away. But I'd be happier if someone wiser
in the ways of Subversion than I could confirm that.
--
Gareth McCaughan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 1 01:18:03 2003