On 2/26/17, Richard Hipp wrote:
> I propose that the next release of Fossil be called "Fossil 2.0"
An alpha version of Fossil 2.0 is now live on the main fossil website:
https://www.fossil-scm.org/
That same Fossil instance also runs SQLite: https://www.sqlite.org/src
This Fossil 2.0
On 3/1/17, Zakero wrote:
>
> Will there be any measurements taken to find out how much of an impact
> there will be to the repository by changing to SHA3?
It would be great if you could make those measurements for us!
--
D. Richard Hipp
d...@sqlite.org
__
On Tue, Feb 28, 2017 at 7:49 PM, Richard Hipp wrote:
>
> (2) Usually only the first 40 digits of SHA3 hashes will be displayed,
> especially on space-constrained tty output.
>
A question on the "Usually" part, mainly for clarification. Fossil will
currently display only as many characters as ne
On 2/28/17, Richard Hipp wrote:
>
> release Fossil 2.0 and Fossil 2.1 simultaneously. The only difference
> between these two version will be that Fossil 2.0 still always
> generates SHA1 hashes on new content whereas Fossil 2.1 generates only
> SHA3 hashes. But both version understand SHA3 hash
Richard Hipp writes:
> Who says we have to display all 64 digits of a SHA2-256 hash in the
> UI?
Correct.
> (1) Fossil 2.x will support only two hashes: SHA1 for legacy and
> SHA3-256 for new check-ins.
>
> (2) Usually only the first 40 digits of SHA3 hashes will be displayed,
> especially on
> Since sending the previous, I've reconsidered and would now like to
> release Fossil 2.0 and Fossil 2.1 simultaneously. The only
> difference between these two version will be that Fossil 2.0 still
> always generates SHA1 hashes on new content whereas Fossil 2.1
> generates only SHA3 hashes. B
> On 2/28/17, Richard Hipp 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
On Feb 28, 2017, at 6:50 PM, Warren Young wrote:
>
> ...for those who run their terminals at > 80 columns
If you go with that, you might want to call isatty(stdout) in case fossil is
being run in a pipeline, so code that tries to parse a hash out of the command
gets the full length.
I say “mi
On Feb 28, 2017, at 6:49 PM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp wrote:
>>
>> Should the SHA3 hashes be SHA3-224 or
>> SHA3-256? In my view, the extra computation and storage overhead for
>> SHA3-256 is minimal and should not present a barrier. However, the
>> extra 8 characters
On 2/28/17, Richard Hipp wrote:
>
> Should the SHA3 hashes be SHA3-224 or
> SHA3-256? In my view, the extra computation and storage overhead for
> SHA3-256 is minimal and should not present a barrier. However, the
> extra 8 characters of hash from SHA3-256 do seem to introduce UI
> challenges.
On Feb 28, 2017, at 2:08 PM, Richard Hipp wrote:
>
> On 2/28/17, Warren Young wrote:
>>
>>> 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 t
On 2/28/17, Warren Young wrote:
>
> I wonder if you’d share what you plan to do with the SQLite repository? Are
> you just going to roll to 2.0 immediately after release, and tell people who
> want to check out the sources via Fossil to upgrade to Fossil 2.0?
The plan is to convert SQLite and Fo
On Feb 28, 2017, at 9:17 AM, Richard Hipp wrote:
>
> This morning I was thinking of using SHA3-256. But after looking at a
> bunch of hashes on-screen, and seeing how long they are, I'm inclined
> now to go with the shorter SHA3-224.
Can you just look at $COLUMNS, $(tput cols), or getmaxyx(3)?
On 2/28/17, Warren Young wrote:
>
>> 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 main
On Feb 28, 2017, at 8:19 AM, Richard Hipp wrote:
>
> On 2/28/17, Richard Hipp 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
On Feb 28, 2017, at 8:11 AM, Richard Hipp wrote:
>
> (3) All new content added to the repository (for example by "fossil
> commit") uses a SHA3-256 hash.
That is a brave step, one I resisted suggesting, but it’s probably for the
best. Defaults matter. If the default is SHA-1, we’ll still be l
rom: drhsql...@gmail.com [mailto:drhsql...@gmail.com] On Behalf Of Richard Hipp
Sent: Tuesday, February 28, 2017 1:09 PM
To: Dillon, Eric W - Norman, OK - Contractor
Cc: fossil-dev
Subject: Re: [fossil-dev] Proposed roadmap for Fossil 2.0
On 2/28/17, Dillon, Eric W - Norman, OK - Contractor
wrote:
>
&
On 2/28/17, Dillon, Eric W - Norman, OK - Contractor
wrote:
>
> Consider that you're primarily only going to be displaying / typing the
> first several hex values anyway.
If it were just the case of showing prefixes, I agree that we might as
well go with 256. But there are situations where the f
I think going with the shorter hash for now is the best move, especially with
regards to possible future enhancements.
Sent from my iPhone
https://urn.to/r/mistachkin
> On Feb 28, 2017, at 11:17 AM, Richard Hipp wrote:
>
> Need your input: Should the new default hash algorithm be SHA3-224 or
Need your input: Should the new default hash algorithm be SHA3-224 or SHA3-256?
Remember, the desire is that there be no options. Fossil should just
do the right thing. VCS users should not have to worry with piddly
details like hashing algorithms. So "make it an option that the user
has to ch
On 2/28/17, Richard Hipp 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
> ti
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 na
On 2/27/17, Andy Bradford wrote:
> Thus said Richard Hipp on Mon, 27 Feb 2017 21:50:43 -0500:
>
>> (9) There are no changes to the file formats, other than relaxing the
>> size constraint on artifact hashes - allowing hash to be greater than
>> or equal to 40 characters rather than requiring i
De : Ben Summers
À : fossil-dev@mailinglists.sqlite.org
Envoyé le : Lundi 27 février 2017 20h56
Objet : Re: [fossil-dev] Proposed roadmap for Fossil 2.0
> On 27 Feb 2017, at 18:59, Richard Hipp wrote:
>
> Maybe I'm making this too hard
>
> Here is plan B:
>
&
I'm convinced enough now that Plan-B won't work, so I'm back on the
Fossil-2.0 path.
--
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
> On 27 Feb 2017, at 18:59, Richard Hipp wrote:
>
> Maybe I'm making this too hard
>
> Here is plan B:
>
> Continue to use SHA1 hashes as the "names" of artifacts. But also
> store a second hash for each artifact as a double-check against
> collisions. This would allow hash collisions to
On Mon, Feb 27, 2017 at 8:59 PM, Richard Hipp wrote:
> The insight here is that SHA1 hash collisions never occur by accident.
> They are always the result of malice. So shunning the artifacts
> involved is never a problem.
>
Isn't that what will already happen with the current version? If someo
On Feb 27, 2017, at 11:59 AM, Richard Hipp wrote:
>
> nobody has yet devised two files that generate identical SHA1 and MD4
> hashes at the same time!
But Joux proved it not especially difficult in this paper, which came up in one
of the earlier SHA-1 threads, to which you responded something l
Maybe I'm making this too hard
Here is plan B:
Continue to use SHA1 hashes as the "names" of artifacts. But also
store a second hash for each artifact as a double-check against
collisions. This would allow hash collisions to be detected
immediately, and the colliding artifacts to be automat
On Sun, Feb 26, 2017 at 11:08 PM, Stephan Beal
wrote:
> How about a '!' (ASCII 33d) card which tells Fossil which hash is in use
> for a given artifact? '!' sorts before all other cards, placing it first in
> the manifest. Maybe even add the artifact type, e.g.:
>
Nevermind - this doesn't solve
Richard Hipp writes:
> I propose that the next release of Fossil be called "Fossil 2.0", that
> it occur before Easter (2017-04-16), and that it have the following
> features:
That’s great news!
> This Fossil-to-Git bridge will not be available in the first release
> but might be a feature add
> On Sun, Feb 26, 2017 at 9:43 PM, Richard Hipp wrote:
>
> > (2) Artifacts can be identified via multiple hash algorithms. The
> > initial implementation will support SHA1 and SHA3-228. (For brevity,
> > SHA3-228 will hereafter be referred to as K228.)
> > (3) The low-level file formats
> >
On Sun, Feb 26, 2017 at 9:43 PM, Richard Hipp wrote:
> (2) Artifacts can be identified via multiple hash algorithms. The
> initial implementation will support SHA1 and SHA3-228. (For brevity,
> SHA3-228 will hereafter be referred to as K228.)
> (3) The low-level file formats
> (https://www.fo
On 2/26/17, Zakero wrote:
>
> Besides the change in the database schema to support a more flexible
> hashing solution, are there any other compatibility breaks that are planned
> or [cs]hould happen?
My goal is to keep changes to a minimum. The only change is to add
support for multiple hash alg
Fossil 2.0 is finally happening, nice!
Besides the change in the database schema to support a more flexible
hashing solution, are there any other compatibility breaks that are planned
or [cs]hould happen? For example:
Command-Line options: There were some old discussions in the mailing-list
abou
This message is cross-posted to fossil-users and fossil-dev.
Follow-ups should go to fossil-dev only, please. Thanks.
I propose that the next release of Fossil be called "Fossil 2.0", that
it occur before Easter (2017-04-16), and that it have the following
features:
(1) Fossil 2.0 is backwards c
36 matches
Mail list logo
