On Tue, Feb 18, 2014 at 11:15 PM, Philip Martin <philip.mar...@wandisco.com> wrote: > Ben Reser <b...@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
