René Hjortskov Nielsen wrote on Sat, Jan 01, 2011 at 09:51:57 +0100: > 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. >
The date is parsed into an apr_time_t, which is a 64-bit type (in APR 1.4.2). > Exactly how is the date supposed to be generated in svnserve? > During commits, the client sends the would-be revprops to the server. But the server overrides svn:date and svn:author and computes them itself. At some point, all revprops undergo validation (see validate_prop() in subversion/libsvn_repos/fs-wrap.c), one of those validations being that svn:date's value is in the expected machine-readable format: % svn pg --revprop -rHEAD svn:date http://svn.apache.org/repos/asf/subversion 2011-01-01T11:33:37.147038Z > 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é
