Re: [fossil-users] Fossil Version 2.0

[Richard Hipp]

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 a tarball of trunk
from https://www.fossil-scm.org/fossil/tarball?uuid=trunk and untar
it, run ./configure; make, and then copy the new "fossil" binary to
somewhere on your $PATH.  Works every time, regardless of what version
of Fossil is currently installed.
-- 
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

[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, 
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
> (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] Fossil Version 2.0

[Warren Young]

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 talking about going straight 
from an old version to the current release.

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:

1. fossil clone http://fossil.scm.org fossil.fossil# v1.29
2. fossil open fossil.fossil version-2.0
3. build, sudo apt-get remove fossil, sudo make install
4. fossil update release   # v2.0
5. build again and reinstall   # current

Is that correct?
___
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] Fossil Version 2.0

[Warren Young]

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 SHA3 on at least trunk?

If so, that’s going to cut off one of my options for bootstrapping to Fossil 
2.x on Debian based systems, which currently ship Fossil 1.29 and soon Fossil 
1.37.  That situation will last until the *next* version of Debian comes out, 
2-3 years from now.

I realize I have other options.  I’m just making sure I’m right to expect that 
bootstrapping via Fossil itself is no longer one of them on Debian for the next 
few years.
___
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

[fossil-users] Fossil 2.0 for win64 [Was: Fossil Version 2.0]

[Jan Nijtmans]

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 in a 64-bit Windows build, this can be found here:


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

[fossil-users] Fossil Version 2.0

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

The key advancement in Fossil 2.0 is that it now supports SHA3-256 as
an alternative hash algorithm used for naming artifacts.  Fossil 2.0
understands both SHA1 and SHA3-256 hashes, but it only generates SHA1
hashes, so it will work seamlessly with Fossil 1.x.  After people have
had an opportunity to upgrade to Fossil-2.0, we will publish new
versions of Fossil that actually generate SHA3-256 hashes.

Please report any problems or concerns to this mailing list, or directly 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

[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