Re: 1.8.8 up for testing/signing

On Tue, Feb 18, 2014 at 11:15 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> 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'"

You mean in a random working copy checked out with my 1.8.8-built
client? Yes, it seems to be always set:

[[[
C:\research\svn\client_build\test\subversion>svn --version
svn, version 1.8.8 (r1568071)
   compiled Feb 15 2014, 20:57:51 on x86-microsoft-windows5.1.2600
...

C:\research\svn\client_build\test>svn co
https://svn.apache.org/repos/asf/subversion/trunk/subversion
...

C:\research\svn\client_build\test>cd subversion

C:\research\svn\client_build\test\subversion>sqlite3 .svn/wc.db
"select local_relpath, translated_size from nodes where kind='file'"
svnserve/cyrus_auth.c|12843
svnserve/server.h|9465
svnserve/svnserve.c|46457
svnserve/winservice.c|17594
svnserve/log-escape.c|5057
svnserve/logger.c|5115
svnserve/svnserve.8|5379
...

C:\research\svn\client_build\test\subversion>sqlite3 .svn/wc.db
"select local_relpath, translated_size from nodes where kind='file'
and translated_size is null"

<nothing>
]]]

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

Unfortunately not.

Okay, so far I'm assuming that the commit probably went through as it
should (since the file size should have been changed), but that
flushing of the output failed somehow (which should, on trunk, report
an error as of r1543868 -- but not on 1.8.x).

I think I can live with that hypothesis for this spurious failure :-).
I'll wrap up my stuff and sign the release.

Thanks all for your help trying to diagnose this.

-- 
Johan