Thanks for your input.
I ended up debugging the subversion and apr code and found the solution.
I corrected the timestamps by making some typecasts in
subversion-1.6.13/apr/time/unix/time.c:
"
APR_DECLARE(apr_time_t) apr_time_now(void)
{
struct timeval tv;
gettimeofday(&tv, NULL);
// RHN: Need to typecast these in order to preserve 8 byte result,
otherwise it gets treated as 4 bytes.
return tv.tv_sec * (long long)APR_USEC_PER_SEC + (long long)tv.tv_usec;
// return tv.tv_sec * APR_USEC_PER_SEC + tv.tv_usec;
}
"
Since we are multiplying with 1000000 here, we get a huge number for
instance
apr_time_t = 1294141942240251 as long long and with my typecasts
binary : 100 10011001 00000011 11100110 11000001 10010011
11111011
apr_time_t : -423521285 without typecasts, apparently represented as a 4
byte type which can hold 4294967295 as the largest positive number.
4294967295 = 11111111 11111111 11111111 11111111
Hence it should be safe to add the above typecasts to the trunk in the apr
code, because the needed size of the timestamp will be the same on a 32-bit
machine aswell on a 64-bit machine.
However, this only fixed the timestamp generation and not the string
generation for the --log-file directive.
Thus removing the error:
"
Bogus date
"
The solution here was also easy and I found that the apr.h file generated by
configure had the wrong output form:
"
/* And APR_OFF_T_FMT */
#define APR_OFF_T_FMT "ld"
//?? APR_INT64_T_FMT
/* And APR_PID_T_FMT */
#define APR_PID_T_FMT "ld"
//?? APR_INT64_T_FMT
"
Basically, I changed the formatters from lld to ld. Please note that I had
to do the same for APR_OFF_T_FMT, which also was formatted wrong.
This fixes the svn import, commit or mkdir error stating:
"
svn: Corrupt node-revision '0.0.t0-1'
svn: Malformed text representation offset line in node-rev
"
I'm not sure that these apr.h changes are universal changes, mainly due to
off_t being defined as 4 bytes and sometimes as 8 bytes.
Hopefully this is useful information for someone :)
Best regards,
René
-----Oprindelig meddelelse-----
From: Daniel Shahaf
Sent: Saturday, January 01, 2011 12:38 PM
To: RenéHjortskov Nielsen
Cc: users_at_subversion.apache.org
Subject: Re: svnserve with corrupt timestamps
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-04 13:12:54 CET