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é
Received on 2011-01-01 12:42:21 CET