Re: [fossil-users] Progress report of Fossil 2.x

[Martin Gagnon]

On Sat, Mar 04, 2017 at 03:07:04PM +0200, Tony Papadimitriou wrote:
> -Original Message- From: Warren Young
> 
> > > (3) New repositories are initialized using SHA3
> > Maybe there should be a “fossil init --sha1” option for the
> > technologically conservative.
> 
> Or, for practical reasons.  So, I second that.
> 
> For example, creating a new repo locally to be hosted by chiselapp (which is
> still running 1.34 BTW) would fail.

In fact, it run 1.36 now (I got corrected recently when I made the same
statement). For some reason, the fossil version we see on the main page
is not the same as the one when you click on a public repository.

> Of course, there is the option of creating on chiselapp and then cloning and
> continuing from there, but it should be able to work both ways because one
> may discover the problem after having done too much work locally.

I'm pretty sure the chiselapp maintainer is on that list and it's
probably on his plan to upgrade to fossil-2.0.

If he does, problem solve, any version of fossil can sync with
chiselapp.

Regards,

-- 
Martin G.

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Tony Papadimitriou]

-Original Message- 
From: Warren Young



(3) New repositories are initialized using SHA3
Maybe there should be a “fossil init --sha1” option for the technologically 
conservative.


Or, for practical reasons.  So, I second that.

For example, creating a new repo locally to be hosted by chiselapp (which is 
still running 1.34 BTW) would fail.
Of course, there is the option of creating on chiselapp and then cloning and 
continuing from there, but it should be able to work both ways because one 
may discover the problem after having done too much work locally.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Warren Young]

On Mar 3, 2017, at 5:58 PM, Warren Young  wrote:
> 
> Ditto new tickets and new tech notes.

Tech notes are tied to a particular checkin, aren’t they?  So never mind on 
that one.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Warren Young]

On Mar 3, 2017, at 5:49 PM, Ron W  wrote:
> 
> I would argue that wiki pages, ticket changes and ticket attachments have 
> parent artfacts. For wiki pages, it would be the most commit of that page.

Okay, but what about new wiki pages?  What is *their* parent?

Ditto new tickets and new tech notes.

Maybe my proposed tip-of-trunk rule should apply here, too.

> bug fixes to 2.0 won't be version number capped.)

The existence of Fossil 2.1 needn’t prevent making fixes to Fossil 2.0.  Just 
use the same version numbering scheme as SQLite: 2.0.1, etc.

What it *does* mean is that we can’t add new *features* to Fossil 2.0 after 2.1 
comes out without breaking the version numbering semantics, but I don’t see how 
that’s even on the table given that there seems to be no interest in making 
Fossil 2.0 a long-term-stable release, with features backported to it.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Ron W]

On Fri, Mar 3, 2017 at 1:33 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Fri, 3 Mar 2017 08:29:06 -0500
> From: Richard Hipp <d...@sqlite.org>
> Subject: Re: [fossil-users] Progress report of Fossil 2.x
>
> (4) When new content is added by means other than a check-in
> (examples: cluster artifacts added by the server on a sync, Wiki
> pages, ticket attachments, or unversioned content files) then use the
> hash algorithm that was used by the most recent check-in.
>

I would argue that wiki pages, ticket changes and ticket attachments have
parent artfacts. For wiki pages, it would be the most commit of that page.
For ticket changes and attachments, it would be the most recent change
commit (or the original ticket artifact itself) for the that ticket.

(Artifacts received during a sync/push/pull operation already have their
own hashes from when/where they were committed.)

Overall, I like this idea of defaulting the hash type of a new artifact to
that of its parent. Fossil development can continue as it has. Then at some
point, change the default new hash type and release that. Maybe 2.1, or
maybe a later one, depending on timing.

(Though maybe consider this an important enough change to warrant jumping
to 3.0. Either way, bug fixes to 2.0 won't be version number capped.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Warren Young]

On Mar 3, 2017, at 6:29 AM, Richard Hipp  wrote:
> 
> (1) When creating a new check-in, use the hash algorithm (SHA1 or
> SHA3) that is used by the primary parent check-in.

I’m not certain what “primary” means in this context.  I assume that it’s a 
distinction for cases where two “parents” exist, but what is the rule that 
determines which one is primary?

For instance, when you’re cherrypicking, I assume the primary is the branch the 
cherrypick is being applied to, rather than the branch the cherrypicked change 
came from.  Is that correct?

How about merges?  Is the primary parent the branch being merged into, rather 
than the branch being merged *in*?

If all of that is correct, then this behavior seems sensible: the ongoing 
branch in both cases keeps its hash default rather than being “tainted” by the 
donor branch.

> (2) Exception to (1) above:  Use SHA3 for new check-ins if the --sha3
> command-line option is used.

I’m confident that the vast majority of Fossil users don’t watch the mailing 
list, so they’ll be somewhat ignorant of the issues.  They may hear that Fossil 
now uses SHA3, and they’ll upgrade and assume they’re using stronger hashes 
now, without realizing that they need to make an affirmative step to switch to 
the new-style hashes.  Then years down the line, they’ll learn that all their 
checkins in that time are still SHA-1, and that there’s no easy way to go back 
and “fix” them, on purpose.

You can say that it’s fixed by documenting the change, but we all know how RTFM 
arguments play out.

On the other hand, it does provide a “don’t touch my tree” option to those who 
believe themselves informed and who wish not to upgrade anyway.

I can see both sides.  It’s a tough choice.

I suppose given the alternative — someone in the latter camp forking Fossil 1.x 
— this is a better choice.

> (3) New repositories are initialized using SHA3

That’s good.  It solves my “defaults matter” concern.  Hopefully the vast 
majority of *future* Fossil users haven’t even started using it yet, so that 
over time, we’ll still end up with a majority of SHA3-based repos.

Maybe there should be a “fossil init --sha1” option for the technologically 
conservative.

> (4) When new content is added by means other than a check-in
> (examples: cluster artifacts added by the server on a sync, Wiki
> pages, ticket attachments, or unversioned content files) then use the
> hash algorithm that was used by the most recent check-in.

That’s kind of random.

If my trunk is SHA3 because I’ve remembered to give --sha3 on a recent checkin 
and my old stable branches are still SHA1 because I update them less than once 
a month on average, my non-checkin artifacts are going to use both until I get 
around to modifying each stable branch at least once while also remembering to 
update the hash algorithm.

I think it would be better to use the hash style of tip-of-trunk instead.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Richard Hipp]

On 3/3/17, Ramon Ribó  wrote:
> ​ ​
> I think it is more clear and simple a "fossil rebuild --sha3"

Rebuilding does not change hashes.  You cannot change the hashes, as
doing so would change the name of historical check-ins.  So if you
have 10 years of check-in history with SHA1 names, those will either
need to all be renamed (which will break historical hyperlinks) or
just keep them as SHA1 and move forward with SHA3-256.

But if the rule is that the child is always the same hash as the
parent, you have to have some way of making an exception so that you
can start using SHA3-256.

-- 
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

Re: [fossil-users] Progress report of Fossil 2.x

[Ramon Ribó]

It sounds ok to me
​ ​
to match the parent checkin style.

However, I do not see a clear advantage to a command "fossil commit
​ ​
--sha3".I think it is more clear and simple a "fossil rebuild --sha3"

RR
2017-03-03 14:29 GMT+01:00 Richard Hipp :

> On 3/3/17, Ramon Ribó  wrote:
> > I would take a more conservative
> > solution:
> >
> > Version 2.1 uses SHA3 for new repositories or when actively required to
> do
> > it (with a rebuild with special options), and continue to use SHA1 for
> > existing repositories.
>
> How about a policy like this for 2.1:
>
> (1) When creating a new check-in, use the hash algorithm (SHA1 or
> SHA3) that is used by the primary parent check-in.
>
> (2) Exception to (1) above:  Use SHA3 for new check-ins if the
> ​​
> --sha3
> command-line option is used.
>
> (3) New repositories are initialized using SHA3
>
> (4) When new content is added by means other than a check-in
> (examples: cluster artifacts added by the server on a sync, Wiki
> pages, ticket attachments, or unversioned content files) then use the
> hash algorithm that was used by the most recent check-in.
> --
> 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

Re: [fossil-users] Progress report of Fossil 2.x

[Richard Hipp]

On 3/3/17, Ramon Ribó  wrote:
> I would take a more conservative
> solution:
>
> Version 2.1 uses SHA3 for new repositories or when actively required to do
> it (with a rebuild with special options), and continue to use SHA1 for
> existing repositories.

How about a policy like this for 2.1:

(1) When creating a new check-in, use the hash algorithm (SHA1 or
SHA3) that is used by the primary parent check-in.

(2) Exception to (1) above:  Use SHA3 for new check-ins if the --sha3
command-line option is used.

(3) New repositories are initialized using SHA3

(4) When new content is added by means other than a check-in
(examples: cluster artifacts added by the server on a sync, Wiki
pages, ticket attachments, or unversioned content files) then use the
hash algorithm that was used by the most recent check-in.
-- 
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

Re: [fossil-users] Progress report of Fossil 2.x

[Ramon Ribó]

Hello,

Given the fact that this is not an urgent requirement (all of us know that
SHA1 works quite well as a hash for vcs), I would take a more conservative
solution:

Version 2.1 uses SHA3 for new repositories or when actively required to do
it (with a rebuild with special options), and continue to use SHA1 for
existing repositories.

ADVANTAGES

1- Avoid the caos of repositories that cannot be accessed because people
have an old version and they do not want/can change the version

2- the motto "fossil is the first vcs to use SHA3..." is still valid

3- People concerned with SHA1 potencial insecurity do "fossil rebuild
-converttosha3"

4- The rest of the world live happily without a new artificial problem that
make their lives more difficult

DISADVANTAGES

The effective conversion of existing fossil repositories to SHA3 will take
a little bit longer. Probably in 2 or 3 years nobody will use the old
versions and a more active conversion can be done. Is this so terrible?

​RR

2017-03-01 23:38 GMT+01:00 Richard Hipp :

> On 3/1/17, Tony Papadimitriou  wrote:
> >
> > I believe DRH asked for feedback.  And that was my feedback.
>
> Thank you.  Your responses are very useful to me.
>
> --
> 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

Re: [fossil-users] Progress report of Fossil 2.x

[Warren Young]

On Mar 1, 2017, at 3:21 PM, Tony Papadimitriou  wrote:
> 
> if I keep my own repos in SHA3 (which I'm for BTW), but I also have to 
> interact with 3rd party sites (like chiselapp) some of which may choose to 
> remain with SHA1 compatible, I would have to keep two different fossils to 
> cope with each case.

That should only be the case if you’re committing to a repo that must remain 
SHA1 based.  If you’re only checking files out of other people’s repositories, 
you can use any Fossil 2.x to do that, as I understand it, even if they’re 
still on Fossil 1.x.

So yes, for any project you’re actively committing to which is refusing to 
upgrade, you’ll have to either learn an exception or lean on them to upgrade.

But again, this is not like the Python situation, since in this case, there is 
a simple upgrade path: upgrade the server to Fossil 2.1+ once all clients are 
on Fossil 2.0 or newer.

The Python divide happened because there is no easy migration *either 
direction*.

> I am not a fossil developer and do not plan to become one.

That’s fine, but it is also the case that we, the beneficiaries of the Fossil 
project, are not obligated to receive *anything*.  If you’re framing your 
requests in terms of what *you* need instead of what those who do the work 
need, you’re going to run into goal and priority mismatches.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Richard Hipp]

On 3/1/17, Tony Papadimitriou  wrote:
>
> I believe DRH asked for feedback.  And that was my feedback.

Thank you.  Your responses are very useful to me.

-- 
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

Re: [fossil-users] Progress report of Fossil 2.x

[Tony Papadimitriou]

-Original Message- 
From: Warren Young


On Mar 1, 2017, at 2:03 AM, Tony Papadimitriou  wrote:

My 'prediction' is that two versions will end up in a similar mess to the 
Python 2.7 vs Python 3.x one.


[all irrelevant Python analysis removed]

I was referring to the fact that Python is divided into two communities with 
no foreseeable deadline for the discontinuance of Python 2.7 in favor of 
3.x.
Those loyal to 2.7 and those loyal to 3.x (like myself).  But regardless of 
which group one belong to, one still needs to keep two installations to cope 
with the various applications or libraries depending on whether those are 
written for Python 2.7 or 3.x


Having two fossils (which is how I understood the plan), one for each case 
(SHA1 and SHA3) may lead to a similar situation.  Why?
For example, if I keep my own repos in SHA3 (which I'm for BTW), but I also 
have to interact with 3rd party sites (like chiselapp) some of which may 
choose to remain with SHA1 compatible, I would have to keep two different 
fossils to cope with each case.  Which means I need to remember where to use 
what.


And, having to remember which version to use depending on the other side 
being compatible or not, will be a practical nuisance.
drh has already said the new versions will warn you when you’re about to 
run into a conflict.


A warning may tell me that I'm using the wrong one, but I would still have 
to try it first before I get the warning.  This is annoying.  You see now, 
if I want to access a git repo, I use git.  But if I want to access a fossil 
repo I will have doubt as to whether to use fossil 2 or fossil 2.1 until 
after I use one and either get lucky or be warned to use the other version.


Even my open check-outs all over my disk.  Which one I opened with 2 and 
which with 2.1?


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?


Certainly. But every binary configuration option potentially doubles the 
size of the test space.  Every existing test has to run in all possible 
configurations.

So, who will do that work, and why?
I’m not asking why you want the work done, I’m asking why that person would 
do it for you, if it is not you doing the work for your own benefit.  What 
itch is that person scratching?


I believe DRH asked for feedback.  And that was my feedback.  Whether it is 
agreeable with you is irrelevant.  I am not a fossil developer and do not 
plan to become one.
If fossil developers do not care for non-developer feedback they shouldn't 
ask for it.  Or, if by providing feedback I'm somehow bound to implement it, 
I should be told about it not to waste my time.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Eduardo Morras]

On Tue, 28 Feb 2017 21:24:42 -0500
Richard Hipp  wrote:

> 
> (9) Your feedback is encouraged and appreciated.

Could Fossil 2.0 change from page model to widget model?

If I want to create a new page, for example a project current status, where I 
want to show open branchs, future events, last five commit tree graph, number 
of "fossil clone/pull/push/sync" received, etc..; I create a new 
current_status.c file and copy paste the code from other pages that implement 
those widgets, doubling (or worse) the code, bugs and maintenance work.

Thanks for your work

---   ---
Eduardo Morras 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Martin Gagnon]

In my case, 

Warren, I agree with you...

-- 
Martin G.

On Wed, Mar 01, 2017 at 10:24:56AM -0700, Warren Young wrote:
> On Mar 1, 2017, at 2:03 AM, Tony Papadimitriou  wrote:
> > 
> > My 'prediction' is that two versions will end up in a similar mess to the 
> > Python 2.7 vs Python 3.x one.
> 
> Python 3 wouldn’t run a large subset of the available Python 2 code, on 
> purpose.  Fossil 2.x will fully use Fossil 1.x DBs.  If you stick to Fossil 
> 2.0, you can even continue to use Fossil 1.x with that same DB.  That doesn’t 
> sound like the Python situation to me at all.
> 
> Python 2 wouldn’t run any Python 3-specific code, but the same is true about 
> Python 2.6 and Python 2.7, which you don’t seem to be worried about.  Rather, 
> you seem to be waving the “disaster once occurred somewhere else under 
> entirely different circumstances” flag.  (I included that latter bit because 
> MD5 vs SHA1 vs SHA3 is not “under entirely different circumstances.”)
> 
> Python 2 to Python 3 was a huge jump in terms of removing old features and 
> such.  None of that is happening here.  Fossil 2 is about a *single feature*.
> 
> Which item in the following document looks like the Fossil 1 to 2 transition 
> to you?
> 
> https://docs.python.org/3/whatsnew/3.0.html
> 
> If you want to never change, never upgrade, stick with Fossil 1.  Fork it if 
> you like; you have that right under Fossil’s 2-clause BSD license.
> 
> > 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!)
> 
> 2.0.1.
> 
> > And, having to remember which version to use depending on the other side 
> > being compatible or not, will be a practical nuisance.
> 
> drh has already said the new versions will warn you when you’re about to run 
> into a conflict.
> 
> > 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?
> 
> Certainly.
> 
> But every binary configuration option potentially doubles the size of the 
> test space.  Every existing test has to run in all possible configurations.
> 
> So, who will do that work, and why?
> 
> I’m not asking why you want the work done, I’m asking why that person would 
> do it for you, if it is not you doing the work for your own benefit.  What 
> itch is that person scratching?
> ___
> 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

Re: [fossil-users] Progress report of Fossil 2.x

[Warren Young]

On Mar 1, 2017, at 2:03 AM, Tony Papadimitriou  wrote:
> 
> My 'prediction' is that two versions will end up in a similar mess to the 
> Python 2.7 vs Python 3.x one.

Python 3 wouldn’t run a large subset of the available Python 2 code, on 
purpose.  Fossil 2.x will fully use Fossil 1.x DBs.  If you stick to Fossil 
2.0, you can even continue to use Fossil 1.x with that same DB.  That doesn’t 
sound like the Python situation to me at all.

Python 2 wouldn’t run any Python 3-specific code, but the same is true about 
Python 2.6 and Python 2.7, which you don’t seem to be worried about.  Rather, 
you seem to be waving the “disaster once occurred somewhere else under entirely 
different circumstances” flag.  (I included that latter bit because MD5 vs SHA1 
vs SHA3 is not “under entirely different circumstances.”)

Python 2 to Python 3 was a huge jump in terms of removing old features and 
such.  None of that is happening here.  Fossil 2 is about a *single feature*.

Which item in the following document looks like the Fossil 1 to 2 transition to 
you?

https://docs.python.org/3/whatsnew/3.0.html

If you want to never change, never upgrade, stick with Fossil 1.  Fork it if 
you like; you have that right under Fossil’s 2-clause BSD license.

> 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!)

2.0.1.

> And, having to remember which version to use depending on the other side 
> being compatible or not, will be a practical nuisance.

drh has already said the new versions will warn you when you’re about to run 
into a conflict.

> 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?

Certainly.

But every binary configuration option potentially doubles the size of the test 
space.  Every existing test has to run in all possible configurations.

So, who will do that work, and why?

I’m not asking why you want the work done, I’m asking why that person would do 
it for you, if it is not you doing the work for your own benefit.  What itch is 
that person scratching?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Umgeher Torgersen]

Tony, I agree with you.

--
//twitter: @umgeher
//xmpp: m...@umgeher.org

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Progress report of Fossil 2.x

[Tony Papadimitriou]

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