Ivan Zhakov writes:
> On 3/13/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> > Ivan Zhakov wrote:
> > > I like this idea. Actually I've never understood why
> > > sleep_for_timestamps stuff is in libsvn_client.
> >
> > I could be wrong, but I think it lives in _client at the moment because we
> > wanted to sleep the minimum amount for a given high-level operation. The
> > worry was with a single person running 'svn' in a scripted situation, not
> > running any-ol-WC-library-consumer. And rather than sleep once per changed
> > file, for example, we much preferred to sleep once per update, for example.
> >
> Michael, thanks for clarification. But I think that wc operations is
> general enough to sleep only once for operation. For example in update
> we can sleep in close_edit(), instead in sleeping after each file.
>
Firstly, I agree that the WC library is better of making a decision of
if/how long to lseep. For example, it could use the last timestamp put into
an entries file as the bases for the sleep instead of the current time.
I actually had an experimental patch for this some time (read years)
ago but I abandonded it because it got messy and I decided it wasn't
worth it.
But wait, I think sleeping when closing a working copy or an edit would be a
mistake. This would mean that update/switch would sleep after each
svn:external and target, instead of once at the end as it is now.
Copy would sleep after each target.
Peter Samuelson writes:
>
> Hmmm, how about moving the sleep functionality into a new
> svn_wc_sleep_for_timestamp called from libsvn_client? The idea is that
> apps could also call it directly if they want.
>
> libsvn_wc would have to keep an internal global for "latest timestamp
> written to an entries file", but that's trivial enough.
Not for a library that can be invoked from multiple threads simultaneously.
So, no, please don't hide the sleeping inside libsvn_wc!
I think I spent enough time on this extra 0.55 seconds we sleep on average
now;)
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 13 09:01:37 2007