Ben Reser <ben_at_reser.org> writes:
> 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:
> http://www.infosec.jmu.edu/documents/jmu-infosec-tr-2009-002.pdf
>
> That paper shows that Windows XP was only capable of providing 1600 nanosecond
> resolution.
>
> 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.
The timestamp problem can only occur if a text modification doesn't
change the filesize and in this case the text modifications always do
change the size. I'm assuming XP does set NODES.translated_size, can
you confirm that?
sqlite3 .svn/wc.db "select local_relpath, translated_size from nodes where kind='file'"
From the failure message posted we know the commit was silent but we
don't know whether it silently created a revision or silently did
nothing. I expect the working copy and repository no longer exist so we
cannot examine them.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-02-18 23:16:01 CET