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

Re: ISO-8601 dates and issue 614

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-05-07 22:05:16 CEST

Karl Fogel wrote:
> Branko Èibej <brane@xbc.nu> writes:
>> >Though I would really like to get some kind of an answer that what
>> >do we want to do with the old style svn_time_to_nts things - is
>> >there something worth keeping there?
>>
>> Assuming you provide a script to convert the WC, I don't think
>> so. It's not worth keeping the month/day name parsing there -- that
>> should go into apr_strptime.
>
> I think we can do this without a grand wc conversion.
>
> The format currently in .svn/entries is instantly distinguishable
> from the format we want in the future. Thus, the conversion
> function that *reads* .svn/entries timestamps merely needs some
> compatibility code for a while (a few months, whatever). The
> writers, of course, would just start using the new format as soon as
> the two-format-accepting reader is in place.

Exactly.

I believe the working directories are no problem - since no "new"
working directory should ever be accessed with an "old" client, so a
simple reading compatibility will suffice.

But we must remember that the change is supposed to change the
timestamp format transmitted through WebDAV as well - so the problem
is a bit bigger.

If we, for example, change all the date to string functions so that
they write the new style dates, but parse both old style and new style
- what will happen in these cases:

1) Old repository, new client

Will repository get some date string from the client that it cannot
parse after the change - if so, where?

2) New repository, old client

Will the new repository send dates to the client it cannot parse? Will
it do this immediately and is it fatal - eg. upgrading repos breaks
all old clients? Or does it just appear on new commits? Or is it not a
problem at all?

If push comes to shove, we can probably upgrade both server and
clients to understand the new format, but still write out the old
format - and then wait a while (possibly a new tarball) for them to
spread everywhere - and then change the writer to writing the new
version. But let's hope we don't have to go into that.

I'll start testing my already changed client sometime soon - but I do
not have a WebDAV server to play with for the test.

But hopefully these issues can be mapped by just looking at the code,
not empirically finding out problem spots.

-- Naked

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 7 22:06:51 2002

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.