> > On 2007-05-04 20:20:15 -0700, Jared Hardy wrote:
> > > I doubt SuSE LES 9 or 10 needs any DST fix, but it's a fairly moot
> > > point since we are past any DST changes.
>
> [Marcus Rueckert]
> > there was an update for the timezone files from suse. did you install
> > them?
>
On 5/5/07, Peter Samuelson <peter@p12n.org> wrote:
> You missed the last half of his sentence, didn't you? He said "it's a
> fairly moot point since we are past any DST changes." He is right.
Hopefully this will settle that part of the debate:
subversion-server:~ # zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Mar 11 09:59:59 2007 UTC = Sun
Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00
2007 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59
2007 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00
2007 PST isdst=0 gmtoff=-28800
I get this result on both the old server and the new server. I haven't
made any changes to get this result, so the DST update must have been
included when I completed the original OS installs/updates in January,
which was well after the SuSE timezone updates were released. I
haven't completed anything but security updates since then. Also note
that my earlier e-mails, which relate my attempts to install the DST
"Hotfixes" on the WinXP SP2 clients, which failed because the updates
were already present.
There is no proof of ANY time/date inconsistency between the
server and clients, in part evidenced by the lack of ANY "bogus date"
related problems in the repository log. The "bogus date" error only
shows up on the Working Copy client side, immediately after a commit
that includes new file or folder additions. The commits never actually
fail, just the WC "revision bump" operation immediately afterwards.
The problem goes away as soon as an update/resolve/revert cycle is
completed on the affected WC. It seems like a real time/date
inconsistency problem would show up more consistently, with all
related client interactions, not just commits of added files. After
testing with new or switched WC's, there is no evidence of the "Bogus
date" messages even occurring with commits that don't include new
adds, yet.
In sum, the outstanding issues seem to be: 1. Bogus date and time
handling in the WC cache for added files and folders. 2. Upon update
of a WC folder that contains files or folders marked for addition on
both the WC and Repository, update fails non-atomically, instead of
resolving the cache consistency gracefully (this is a long standing,
long annoying, basic design issue). 3. Revision bump after commit is
currently useless (bumped revision numbers don't traverse up the WC
tree properly, and a recursive WC cache scan is always done regardless
of WC version numbers).
Thanks,
Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 6 02:05:11 2007