Joerg Hessdoerfer <Joerg.Hessdoerfer@sea-gmbh.com> writes:
> > <entry
> > committed-rev="4"
> > name="StartSequencer.vi"
> > text-time="1969-12-31T23:00:00.000000Z"
> > committed-date="2003-03-17T10:07:55.387935Z"
> > checksum="769382c1c08475bff7cfbb9071302ab2"
> > last-author="jh"
> > kind="file"
> > prop-time="2003-03-17T10:00:27.656250Z"/>
> >
> > The 1969 error causes svn_wc__atts_to_entry to return an error which
> > causes handle_start_tag to call svn_xml_signal_bailout. When this
> > happens I think handle_start_tag should return immediately and not do
> > any further processing.
> >
> > I don't know why there are dodgy dates in your entries file. What is
> > the Windows timestamp on StartSequencer.vi?
>
> Yow! The windows timestamp for this file IS NOT PRESENT! Now talk about an OS!
It appears that APR has some built in epoch limits, and so Subversion
is able to write that 1969 date, but is not able to read it back.
That's unfortunate. I wonder how common the use of files with pre
1970 dates is going to be, do we need to fix this bug?
The best solution from a Subversion point of view would be to have APR
lift the pre-epoch restriction. Alternatively, Subversion could do
without the timestamps when APR fails to handle them (the timestamps
are simply an optimisation) but I don't know how easy that would be to
implement in the Subversion code.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 18 19:31:55 2003