René Hjortskov Nielsen wrote on Tue, Jan 04, 2011 at 13:08:51 +0100:
> Hopefully this is useful information for someone :)
It's useful, yes. You could pass this information directly to the APR
project: http://apr.apache.org/ should identify the mailing list you
need.
Thanks,
Daniel
René Hjortskov Nielsen wrote on Tue, Jan 04, 2011 at 13:08:51 +0100:
> 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:46:40 CET