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
Received on Sun May 19 16:01:07 2002