subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From René Hjortskov Nielsen <>
Subject Re: svnserve with corrupt timestamps and malformed text representation
Date Tue, 04 Jan 2011 12:08:51 GMT
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 
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 
apr_time_t   = 1294141942240251 as long long and with my typecasts
binary           :  100 10011001 00000011 11100110 11000001 10010011 
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,

-----Oprindelig meddelelse----- 
From: Daniel Shahaf
Sent: Saturday, January 01, 2011 12:38 PM
To: RenéHjortskov Nielsen
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 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 xx newrepo get-latest-rev
> 5191 1969-12-31T23:57:53.-394901Z xx newrepo reparent /
> 5191 1969-12-31T23:57:53.-394901Z xx newrepo stat /@0
> 5192 1969-12-31T23:57:53.-334901Z 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

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

> 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é 

View raw message