I’ve cross compiled subversion 1.6.15 on my i686 to the target system armv4l (product ib-nas3221-b).
Everything seems to work, I can work with my old repository which has been moved to the target system. However, when I do a commit through svnserve running on the target I get the commonly known and unresolved “bug” Bogus date. I have tested that this is not the case when using the repository with my client (TortoiseSVN) directly, i.e. file protocol. I have noticed that all svnserve timestamps are bad, even in the logfile when running svnserve with –log-file. Here are some sample logfile timestamps from svnserve: 5191 1969-12-31T23:57:53.-414901Z 192.168.5.4 xx newrepo open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / SVN/1.6.15%20(r1038135) - 5191 1969-12-31T23:57:53.-404901Z 192.168.5.4 xx newrepo get-latest-rev 5191 1969-12-31T23:57:53.-394901Z 192.168.5.4 xx newrepo reparent / 5191 1969-12-31T23:57:53.-394901Z 192.168.5.4 xx newrepo stat /@0 5192 1969-12-31T23:57:53.-334901Z 192.168.5.4 xx newrepo open 2 cap=(edit-pipeline svndiff1 absent-entries depth mergeinfo log-revprops) / SVN/1.6.15%20(r1038135) - Date on my target server with date command was: Sat Dec 31 14:03:57 CST 2010 On a commit through svnserve the same bogus dates are written everywhere, rendering the repository unsuable, i.e. newrepo/db/revprops/0/1 I am woundering if this is a 32-/64-bit issue, even though both my i686 build system and the armv4l target system are 32-bit editions. Exactly how is the date supposed to be generated in svnserve? Currently my understanding is that dates are mapped back and forth from human readable formats to machine format, thus I suspect that this could be the source of the problem. Unfortunately I do not have the time to start writing debug code to isolate the problem at hand and was hoping that someone with enough insight could provide the debug code, which I happily will recompile and test. Best regards and a happy new year, René
