> -----Original Message-----
> From: Julian Foad [mailto:julianfoad_at_btopenworld.com]
> Sent: donderdag 4 april 2013 22:51
> To: Ben Reser
> Cc: Philip Martin; Subversion Development
> Subject: Re: [PATCH] Sleep for timestamps in the right places
>
> Ben Reser wrote:
> > On Tue, Apr 2, 2013 at 1:04 PM, Julian Foad wrote:
> >> Philip Martin wrote:
> >>> Could we check use-commit-times and avoid the sleep? Either before
> >>> sleeping or perhaps where we set sleep_here TRUE.
> >>
> >> OK, thanks; I did that (inside update_internal()), and a few more
things,
> >> and committed r1463721.
> >
> > I'm not sure this is such a great idea. If you use commit times it
> > may or may not be safe to skip sleeping. I discussed this a bit with
> > Philip on IRC today where he pointed out sleeping may also in some
> > cases may create problems as well.
> >
> > Commit timestamps may be in the past or the future.
> >
> > If they are less than the timestamp resolution of the file system in
> > the past then an immediate change to the file after the command exists
> > will not be visible to Subversion. This can be resolved by sleeping.
> >
> > If the timestamp is in the future then sleeping may bring you within
> > range of the timestamp resolution of the file system, resulting in the
> > same problem. The future timestamp problem can be dealt with by
> > keeping clocks in sync (NTP).
>
> Yes, we shan't attempt to handle the clock-skew problem at the
> moment. That is one of the issues that the enhancements suggested in
> <http://subversion.tigris.org/issues/show_bug.cgi?id=4342>, "Sleep for
> timestamps should be determined by libsvn_wc" could address.
>
> > It'd be easy to say "If you're doing the type of automation that's
> > bound to run into these sorts of problems don't use commit times."
> > However, I suspect there's times where you want to do both. As it is
> > right now if you're keeping your clocks in sync it should work okay.
> > But unless I'm missing something that's not the case after this
> > change.
>
> That's true, given that the current implementation doesn't look at the
> timestamps when deciding whether or how long to sleep. So the safe thing
> to do is reintroduce a sleep even if using commit times, for all
applicable
> operations (checkout, update, switch, revert).
>
> I'll commit this soon. (Running tests now.)
Note that calling svn_wc_text_modified_p2() while having a working copy lock
can update stored timestamps, so calling a status function while having a
working copy lock can have this effect.
Also note that we don't just sleep a second. We sleep until some fraction
after the next second starts. So by average this is about 0.6 seconds...
And we use some of this time to see if you have a modern filesystem that
stores more timestamp details than just seconds (by looking at the existing
filesystem node passed to the function) and if you have such a filesystem we
don't sleep at all.
With micro or sometimes nanosecond precision timestamps stored there is no
reason to sleep as an updated file is certain to have a different timestamp.
Bert
Received on 2013-04-05 13:15:22 CEST