Re: [fossil-dev] Fossil 2.0 and mv/rm behaviour
This is what happened as I understand it: The codename "fossil 2.0" has been used for a few years whenever a change that would potentially break backwards compatibility was suggested. Such a version, if ever released, would require more planning, more testing and more notice to users then a "regular" cycle release. Since the SHA1 issue caught everyone by surprise (side note: Why were we all caught by surprise when this was known to be theoretically possible for over a decade?), there was an urgent need to fix this issue, which would break backwards compatibility. So "fossil 2.0" happened in a rush, without time to track down and implement all the issues waiting for "fossil 2.0". -- END HISTORY LESSON -- That being said, time for my suggestion: Since version 2.0 ended up NOT breaking anything, and the breaking changes will be in 2.1 and 2.2, maybe we can still change some of the things that were waiting for a "breaking" release in 2.1 or 2.2? Since the SHA1 issue will not really be fixed until version 2.1, but version 2.2 will still be breaking some backwards compatibility (pushing from a pre-2.1 client will not be possible) , how about releasing 2.1 with only a note in the release notes that this will be the last version with behaviors X, Y and Z, and then take the time for 2.2 to actually implement/change what is needed? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Fossil 2.0 and mv/rm behaviour
On Mar 6, 2017, at 12:21 AM, Tino Lange wrote: > > Now that Fossil 2.0 is out I wonder if line 42 here: > https://www.fossil-scm.org/index.html/artifact?ln=on&name=f23144d54a286503 > should be turned to 1 to change the mv-and-rm behaviour? While I would like to see that behavior become the default, too, I can forgive the Fossil developers for indicating at one point that this behavior would change at “Fossil 2.0”, since they clearly had no idea at the time that they’d be using that number for something entirely different. Maybe for Fossil 2.2, though, after all this SHA3 brouhaha quiets down, and after the Fossil devs have had time to clear the backlog of SQLite issues that have built up as a result of this digression? I’ve been running my Fossil binaries configured like this for a couple of years now, probably. There have been no serious problems. I put the qualifier in there because Fossil isn’t always smart about mv --hard in the face of multiple files. I’ve found it best to wrap such things up in a “for” loop at the shell prompt whenever I’m doing something the slightest bit tricky. (Sorry, no simple test case available at this time.) ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
[fossil-dev] Fossil 2.0 and mv/rm behaviour
Hi! Now that Fossil 2.0 is out I wonder if line 42 here: https://www.fossil-scm.org/index.html/artifact?ln=on&name=f23144d54a286503 should be turned to 1 to change the mv-and-rm behaviour? Cheers, Tino ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
