Work is ongoing and subject to change. But the way this is playing out is as follows:
(1) When you upgrade to Fossil 2.0, you can immediately start using it on your existing repositories. There is no need to run "fossil rebuild" or anything like that. It just works. (2) All legacy SHA1 hash names are preserved and continue to be used. (3) All new content added to the repository (for example by "fossil commit") uses a SHA3-256 hash. The hash names are longer (64 bytes instead of 40) but otherwise everything works the same as before. Users might not notice the upgrade. (4) There are no hash options. You cannot choose to use any hash algorithm other than SHA3-256 for new content. This is a deliberate design choice intended to simplify operation. Developers should not have to worry about what hash algorithm their VCS is using - it should just do the right thing. (5) Older versions of Fossil will still be able to read the repository after new SHA3 content has been entered, but the older Fossils will not understand the new content and won't display it. If you "fossil push" or "fossil pull" or "fossil clone" then the remote side should also be Fossil 2.0 or later so that the new SHA3 hashes can be understood. (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. All of the above is subject to change. Please provide feedback. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
