Karl Fogel wrote:
> Branko ╚ibej <firstname.lastname@example.org> 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.
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.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue May 7 22:06:51 2002