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ó
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
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
On Mar 3, 2017, at 5:07 PM, Warren Young wrote:
>
> bootstrapping via Fossil itself is no longer one of them on Debian for the
> next few years.
On re-reading that, I see that it’s not as clear as it should be. When I said
bootstrapping with Fossil wasn’t possible, I was
On Mar 3, 2017, at 6:45 AM, Richard Hipp wrote:
>
> Fossil version 2.0 is now available on the Fossil website
> we will publish new versions of Fossil that actually generate SHA3-256 hashes.
I presume you will also be dogfooding it on fossil-scm.org, complete with
moving to
On Fri, Mar 3, 2017 at 1:33 PM,
wrote:
>
> Date: Fri, 3 Mar 2017 08:29:06 -0500
> From: Richard Hipp
> Subject: Re: [fossil-users] Progress report of Fossil 2.x
>
> (4) When new content is added by means other than a check-in
>
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
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
On 3/3/17, Warren Young wrote:
>
> If I understand the plan correctly, even if fossil-scm.org goes to Fossil
> 2.1+ and SHA3 immediately, I can still bootstrap up from Fossil 1.x using
> Fossil itself if I do it in two stages:
The web interface will works fine. Just download
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
Fossil version 2.0 is now available on the Fossil website
(https://www.fossil-scm.org/download.html) and its mirrors.
Fossil 2.0 is 100% backwards compatible with Fossil 1.x. Do no worry
about the change in the first digit.
The key advancement in Fossil 2.0 is that it now supports SHA3-256 as
2017-03-03 14:45 GMT+01:00 Richard Hipp:
> Fossil version 2.0 is now available on the Fossil website
> (https://www.fossil-scm.org/download.html) and its mirrors.
>
> Fossil 2.0 is 100% backwards compatible with Fossil 1.x. Do no worry
> about the change in the first digit.
For anyone interested
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
13 matches
Mail list logo