On 03/01/17 17:06, sky5w...@gmail.com wrote:
[---]
> 3. Fossil 2.0+ delivered as dll.
>I use the exe for remote repo server, but automate my check-in/out's.
>That would be more fluid without parsing CLI text.
This has brought up a few times before, and there are no such plans
(not for 2
On 3/1/17, Sean Woods wrote:
> Do you keep updating Fossil 1.x? Will changes to the Fossil 1.x line be
> ported to 2.x?
No. Fossil 2.0 is a drop-in replace for Fossil 1.x. If you find a
problem in historical Fossil 1.x, then the solution is to upgrade to
Fossil 2.0.
--
D. Richard Hipp
d...@s
Do you keep updating Fossil 1.x? Will changes to the Fossil 1.x line be
ported to 2.x?
On Wed, Mar 1, 2017, at 11:36 AM, Richard Hipp wrote:
> On 3/1/17, sky5w...@gmail.com wrote:
> > More 2.0+ requests...
>
> Fossil 2.0 will say focused on one thing: SHA3
>
> --
> D. Richard Hipp
> d...@sql
On 3/1/17, sky5w...@gmail.com wrote:
> More 2.0+ requests...
Fossil 2.0 will say focused on one thing: SHA3
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/ma
Sorry for double post, I got spammed between reply and lost track of what I
deleted. :(
On Wed, Mar 1, 2017 at 11:14 AM, wrote:
> Cool!
> More 2.0+ requests...
> 1. 'Prune' repo to deliver a branch or whatever as a new repo.
>Ideally, history preserved from point of prune forward.
> 2. Unver
Cool!
More 2.0+ requests...
1. 'Prune' repo to deliver a branch or whatever as a new repo.
Ideally, history preserved from point of prune forward.
2. Unversioned files supported with check in/out.
Current approach is confusing(that may be intentional?).
3. Fossil 2.0+ delivered as dll.
I u
All sha's aside:
1. 'Prune' repo to deliver a branch or whatever as a new repo.
Ideally, history preserved from point of prune forward.
2. Unversioned files supported with check in/out.
Current approach is confusing(that may be intentional?).
3. Fossil 2.0+ delivered as dll.
I use the exe
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 Feb 27, 2017, at 6:28 PM, Tony Papadimitriou wrote:
>
> On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote:
>
>>> how is it possible for someone to inject a 'bad' file with the same SHA1 as
>>> a 'good' file already in the repo?
>> Your attacker could be MITM’d into the sync stream. I g
-Original Message-
From: Warren Young
On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote:
how is it possible for someone to inject a 'bad' file with the same SHA1
as a 'good' file already in the repo?
Your attacker could be MITM’d into the sync stream. I gave an example
requiring
On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou wrote:
>
> how is it possible for someone to inject a 'bad' file with the same SHA1 as a
> 'good' file already in the repo?
Your attacker could be MITM’d into the sync stream. I gave an example
requiring only the current SHA-1 collision technolo
On 27/02/2017 16:14, Richard Hipp
wrote:
On 2/26/17, Ron Aaron wrote:
>From a performance standpoint, I would rather see Fossil adopt the
BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has
adjustable output hash size.
On 2/26/17, Ron Aaron wrote:
>
> From a performance standpoint, I would rather see Fossil adopt the
> BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has
> adjustable output hash size.
>
Please write and check-in code (on the "fossil-2.0" branch) that
implements BLAKE2 in a ma
I'm happy to see you thinking along those lines.
>From a performance standpoint, I would rather see Fossil adopt the
BLAKE2 hash, as it is one of the fastest of the SHA3 finalists, and has
adjustable output hash size.
On 27/02/2017 3:48, Richard Hipp wrote:
> On 2/26/17, Tony Papadimitriou wrot
On 2/26/17, Tony Papadimitriou wrote:
>
> how urgent is the need to
> transition away from SHA1?
>
From a technical standpoint, it is not very urgent, in my assessment.
However, from a PR standpoint, I think it needs to happen quickly.
It can also be a big PR win if we are able to boast that Fo
Leaving aside for a moment the consequences in general of the presumed
imminent SHA1 collapse (and some of the valid points already made by Linus
regarding Git):
If FOSSIL will refuse (and I actually tried it with those two same SHA1
PDFs) to accept a file (commit, push, pull) with the same SH
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
17 matches
Mail list logo
