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

Re: 1.8.8 up for testing/signing

From: Ben Reser <ben_at_reser.org>
Date: Tue, 18 Feb 2014 12:40:41 -0800

On 2/18/14, 12:22 PM, Johan Corveleyn wrote:
> Thanks for the hint. Now, this wasn't an error path (just a commit
> that should have succeeded and should've written something to stdout).
> I'm not sure how I can determine that this is the likely cause ... I
> can't seem to reproduce it, no matter how hard I try :-(.

I unfortunately don't have any good suggestions. However, I'm assuming we made
the change to flush stdout when there wasn't an error for some good reason.

> Bert also suggested another possible reason: perhaps it was no
> flushing problem, but rather that the commit didn't do anything
> because the commit crawler didn't find any mods (perhaps because of
> timestamp granularity stuff). If my ramdisk would have been a FAT32
> partition, that might be a possible explanation, but "unfortunately"
> it's an NTFS ramdisk ... I don't see how this could have happened.
> Perhaps someone can hypothesize something, and talk me through a
> possible scenario?

NTFS itself has 100 nanosecond resolution, but I don't believe you can actually
achieve that resolution with Windows XP. See:

That paper shows that Windows XP was only capable of providing 1600 nanosecond

I don't know if this is enough to drive the issue you're seeing. But it's
useful to realize that NTFS's storage capability doesn't reflect the actual
accuracy of timestamps in practice.
Received on 2014-02-18 21:41:11 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.