[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Wrong date/time in "svn log" output

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2005-12-06 16:58:46 CET

On 12/6/05, Brandt, Servatius <Servatius.Brandt@fujitsu-siemens.com> wrote:
> Ben Collins-Sussman wrote:
>
> > This is a famous bug in the GetTickCount() windows API -- it overflows
> > after 49 days, being a 32-bit number. You can read about it here, in
> > the commentary:
> >
> >
> http://www.techspot.com/news/15637-microsoft-servers-leave-800-planes-in
> -the-air.html
>
> Thanks, this explains what happens.
>
> Could you do one of the following:
>
> 1) Work around the GetTickCount() limitation by watching and
> counting overflows yourself or use a different API function?
> (Don't know whether this is possible.)
>
> Or:
>
> 2) Add a remark to the Subversion documentation that on Windows
> systems a reboot is necessary at least after 49 days?
>
>

I don't think this is a Subversion bug, because it doesn't call
GetTickCount() anywhere at all. I think it is more likely a bug in
Cygwin's "unix translation" layer. My suspicion is that Subversion
calls the APR time functions to get the current system time, then APR
calls the standard unix time functions, and then Cygwin translates the
unix call into a windows GetTickCount().

How about this: don't run an svn server under cygwin. There's
absolutely no reason to use cygwins hack-y "translation" layer when
true, 100% native windows binaries are available. Sure, cygwin is
generally convenient, and so is the 'native' cygwin svn client. But
for something as important as a server process, I wouldn't trust
cygwin any farther than I can throw it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 6 17:14:36 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.