> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 5 april 2013 14:09
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org; julianfoad_at_btopenworld.com
> Subject: Re: FW: [PATCH] Sleep for timestamps in the right places
>
> "Bert Huijben" <bert_at_qqmail.nl> writes:
>
> > 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.
>
> We still sleep on filesystems with high resolution but we switch to a
> millisecond sleep instead of a second sleep.
>
> I still think that sleeping when use-commit-times=yes is odd. With
> use-commit-times=no we know that timestamps set by the operation for are
> in the past and the sleep takes account of the limited precision. With
> use-commit-times=yes we simply don't know that timestamps are in the
> past: they could be years in the past, slightly in the past, slightly in
> the future or years in the future. Sleeping for 1s, or 1ms, in the hope
> that it will solve problems with one tiny part of that range when it
> could also create problems in another tiny part of that range is odd.
While traversing the working copy we might update the record for files to
mark/record them as unchanged, even though we didn't write them and didn't
set the timestamp ourselves. (E.g. files that were merged. Or just updated
externally)
I don't really care about whether this case is interesting enough to
perform/not perform the sleep. I try to avoid use-commit-times where
possible.
And optimizing for this nonstandard setting is not really interesting for
me. My users usually won't see the sleep anyway.
Bert
Received on 2013-04-05 15:18:16 CEST