On Mar 5, 2017, at 9:15 AM, Richard Hipp <[email protected]> wrote: > > On 3/5/17, Lonnie Abelbeck <[email protected]> wrote: >> fossil init --sha1 repo.fossil > > why would you want to do that?
One may have a public-facing repo and want it to be readable by the fossil binaries packaged for all common OSes. That’s going to be Fossil 1.x for several years yet, if only because of some unfortunate timing with respect to Debian’s Stretch’s hard-freeze date, which passed while Fossil 1.37 was current. I’ve got such a public-facing repo, but because the project is young enough and small enough, I’m going to be able to force a Fossil 2.1+ switch by fiat. I can imagine that not all projects will be able to do so as easily. I am quite happy with the new hash-policy design for this sort of reason. (Thank you!) It lets the server upgrade to Fossil 2.1+ while still serving Fossil 1.x clients. I’m going to force the Fossil 2.x switch for my own project because any future problems we have with SHA1 will be greatly mitigated if all the SHA1 commits are buried years in the past by at least one SHA3 commit before practical SHA1 attacks become inexpensive. Since some branches may remain open but largely dormant for years, that means I need to start soon. Yes, I’ve been on both sides of this issue. It isn’t a simple matter. You’ve negotiated it very nicely! _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
