My 'prediction' is that two versions will end up in a similar mess to the
Python 2.7 vs Python 3.x one.
Also, Fossil 2.0 will not be able able to get any significant updates due to
version collision with 2.1 (so, maybe 2.0 and 3.0 -- oops, more like
Python!)
And, having to remember which version to use depending on the other side
being compatible or not, will be a practical nuisance.
Would it not be possible to have a single version that simply keeps an extra
table with the SHA3 and the presence of the table alone will determine which
way to go?
BTW, you would not even need to expose SHA3 to the end user, only use it
internally for verification -- only difference is that you have to accept
SHA1 collisions but not SHA3 (or other) collisions.
The alternate hash could really be anything (from the available choices) the
user chooses -- even possibly let the user write their own plugins to make
their repos truly personal as no one without the same hash method will be
able to commit to it.
My 0.01 eurocent.
-----Original Message-----
From: Richard Hipp
Sent: Wednesday, March 01, 2017 4:24 AM
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Progress report of Fossil 2.x
Discussion of Fossil 2.x continues on the fossil-dev mailing list. I
am offering this update to the broader fossil-users community to
elicit feedback.
(1) Moving forward, Fossil repositories will be able to name artifacts
using either the legacy SHA1 hash or using a SHA3-256 hash. Both
hashes can be used within the same repository. Long running projects,
such as SQLite, can continue forward without changing any existing
hash values yet still use SHA3 names for new content
(2) For most display purposes, the 64-digit SHA3-256 hash will be
truncated to the same 40-character length as a SHA1 hash. Most users
will probably never notice that a hash algorithm change has occurred.
The full 256-bit hash will be carried internally for collision
detection, and will be accessible on some detailed UI screens.
(3) To facility trouble-free upgrades, there will be a simultaneous
release of Fossil 2.0 and Fossil 2.1.
(4) Fossil 2.0 will be fully compatible with Fossil 1.x. No "fossil
rebuild" is needed. Just drop the new executable on your $PATH and
continue typing fossil commands just like you always have. Fossil 2.0
will sync and clone with Fossil 1.x and will read and write all the
same repository files as Fossil 1.x. The are completely
interchangeable. The only difference is that Fossil 2.0 understands
SHA3 hashes whereas Fossil 1.x does not. But Fossil 2.0 does not
generate any SHA3 artifacts so it will not do anything to confuse
Fossil 1.x.
(5) Fossil 2.1 is almost identical to Fossil 2.0. The only difference
is that Fossil 2.1 always uses SHA3 names for new content. Thus
Fossil 2.1 will generate artifacts that Fossil 1.x does not know how
to interpret. And Fossil 2.1 will have difficulty syncing with Fossil
1.x. But Fossil 2.0 and Fossil 2.1 will interoperate seamlessly.
(6) The upgrade process goes like this: First begin deploying Fossil
2.0 everywhere within the organization. Once Fossil 2.0 is deployed
everywhere, then go back and start deploying Fossil 2.1 everywhere.
As long as nobody tries to use Fossil 2.1 until after everyone has
stopped using Fossil 1.x, no incompatibilities will be occur and
everything should continue to operate normally.
(7) After Fossil 2.1 is deployed, all new content will use SHA3 hashes
exclusively. Older content will continue to be named by the legacy
SHA1 hashes so existing hyperlinks and command line arguments will
continue to work just as if no hash algorithm change had ever
occurred.
(8) The above is just a plan. Everything is subject to change.
(9) Your feedback is encouraged and appreciated.
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
