On Feb 28, 2017, at 8:19 AM, Richard Hipp <d...@sqlite.org> wrote: > > On 2/28/17, Richard Hipp <d...@sqlite.org> wrote: >> >> (4) There are no hash options. You cannot choose to use any hash >> algorithm other than SHA3-256 for new content. >> >> (6) The only complication to upgrading is that you need to update all >> of your fossil (or fossil.exe) binaries to version 2.0 at the same >> time. > > Maybe a better approach is for Fossil 2.0 to use SHA3 hashes for new > content if and only if the repository already contains some other SHA3 > content.
That sounds like making a table scan on every checkin. If so, that does not appeal. > Then after a month or so we can release Fossil 2.1, in which all new > content is always SHA3. If there’s going to be a transition time, I think it would need to be something like a year or two, during which both Fossil 1 and Fossil 2 are actively maintained. If you only want a 1 month transition time, I think it would be just as effective to send an email out a month in advance of your planned Fossil 2.0 server upgrade to tell the users they need to upgrade their clients in advance of the switchover. _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
