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

FW: [PATCH] Sleep for timestamps in the right places

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 5 Apr 2013 13:14:42 +0200

> -----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
> >> 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
> 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.

Received on 2013-04-05 13:15:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.