ISO-8601 dates still

[Nuutti Kotivuori <na...@iki.fi>]

Well, I've been busy lately with other stuff (and I just cut my finger
with a bread knife so my typing is slow), but this thing has given me
a lot of thought.

If we decide to change the date format right off, there will be
breakage - I have confirmed that now. So, there's a few requirements
for this to happen painlessly. I see a few choices here, kind of.

First choice is that we somehow keep the compatibility right off -
this would mean that from an existing svn and existing working copy
(including the bootstrap tarball), one needs to be able to do 'svn co'
and 'svn up' and get the files for compilation. Right now, however, it
seems that after we change the timestamp format, any parsing of the
new timestamps by the old clients will cause a segfault. So, if a
client tries to update to a revision that has a new timestamp, it will
break. I have not verified if it is possible to checkout an older
revision, which does not have the new timestamps - but I would assume
it is. So all we would need to do is to advice people that they need
to check out revision xxx and compile that to get the latest revision.

The second choice is to make a new bootstrap tarball that is a
mandatory download to everyone updating. I don't know how nice of a
solution this would be. This would ofcourse all the updating issues -
we just have an incompatible revision, though the new revision is
backward compatible.

And the third choice is to do what I mentioned in the very beginning -
make a revision that understand the new timestamps, but produces old
timestamps still. And then postpone the timestamp changing until a new
bootstrap tarball is released naturally. This would be quite a catch
all solution - it would enable us to incrementally fix everything
everywhere and just do the jump whenever it's suitable. But ofcourse
it's a bit elaborate for such a small change.

But one thing is for certain - we cannot just ignore the issue of
compatibility by saying that this is pre-alpha - we need a way for
people to be able to update to the latest revision atleast :)

A short guess list assisted by grep of what would break when the
timeformat is changed:

  libsvn_wc - obviously, if any new timestamps are encountered with an
  old client, segfault-o-rama here we come.

  svnlook - the do_date routine will break majorly as well.

  libsvn_repos/rev_hunt.c - I have no idea what this is used for and
  when the breakage would appear.

So, opinions and suggestions welcome on how to proceed - in the
meanwhile, I will be testing these things locally just in case I could
find out something new. I will also be starting a new thread about
human presented dates, which is an entirely different matter.

-- Naked


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: ISO-8601 dates still

[Ben Collins-Sussman <su...@collab.net>]

Nuutti Kotivuori <na...@iki.fi> writes:

> And the third choice is to do what I mentioned in the very beginning -
> make a revision that understand the new timestamps, but produces old
> timestamps still. And then postpone the timestamp changing until a new
> bootstrap tarball is released naturally. 

This sounds like the best strategy, as you mentioned earlier:

"Phase 1":  libsvn_wc understands both kinds of timestamps.  It writes
new-style timestamps to the entries file, but sends old-style
timestamps over the network.  Hopefully this can be done before the
pre-alpha milestone.

"Phase 2":  after we upgrade our server for pre-alpha, the client can
start sending new-style timestamps to the server.


The issue, as you pointed out, is that it would be bad to have recent
revisions with new-style timestamps on them; it means older clients
would choke when they tried to update.  The server should never be
sending new-style stamps until there's a new tarball out there that
can deal with them.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org