Re: [fossil-users] handling backports
On Nov 4, 2015, at 1:17 AM, Andy Bradford wrote: > yabbawhap > (released in 1991) still compiles (presumably correctly), unmodified, on > a modern OpenBSD system using GCC, as do numerous other packages that > are well over 15 years old and have received no modifications. It seems like with almost every new Linux distro release, a lot of software requires #includes it never required before. On reflection, it probably isn’t a change in GCC, but instead in glibc or libstdc++. I believe this is because as time goes on, casual header interdependencies are being broken in order to reduce build times. That in turn means that code that relied on another header to bring in something really common like stdlib.h often breaks when you build it on a newer system. The fix is to add the “missing” #includes, which weren’t needed on older systems. You may say that the fault is in the code, because the man page documented the necessary #includes. But, the same pressure to reduce rebuild time causes software maintainers to remove “unnecessary” #includes on their end, too. My favorite example of this is the BSD sockets headers. The Linux man page for inet_ntoa() claims it needs #include #include #include All that for just one function? The OS X man page is more sensible, saying you need only arpa/inet.h. So, is code “wrong” to include only arpa/inet.h if it also builds on Linux? It may fail to build 2 years from now when the implicit #include of netinet/in.h is removed. You can call that a coding error, but to me, it’s just an everyday maintenance hassle. ___ 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] handling backports
Thus said Warren Young on Tue, 03 Nov 2015 15:44:04 -0700: > This isn't a LaTeX issue at all. I see substantially the same problem > with #includes on newer versions of GCC. Older versions of the code > carry a presumption about the tools used to build the code. You can't > expect 10-year-old sources to build correctly under bleeding-edge > tools. I'm not sure what is meant by ``bleeding-edge'' tools, but yabbawhap (released in 1991) still compiles (presumably correctly), unmodified, on a modern OpenBSD system using GCC, as do numerous other packages that are well over 15 years old and have received no modifications. Andy -- TAI64 timestamp: 40005639bf20 ___ 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] handling backports
On 3 November 2015 at 15:14, Richard Hipp wrote: > > That is exactly what --cherrypick is for. > > You can see a couple of recent examples of this in the SQLite source > tree, where we took a couple bug fixes from trunk and > cherrypick-merged them into the branch-3.9 branch to create the recent > 3.9.2 release. Do you think the --cherrypick option deserves a little info about it or is it self explanatory with what's written? https://www.fossil-scm.org/index.html/help?cmd=merge Except, if either of the --cherrypick or --backout options are used only the changes associated with the single check-in VERSION are merged. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] handling backports
On 11/3/15, Warren Young wrote: > On Nov 3, 2015, at 11:48 AM, Eduard wrote: >> >> Scenario 1: Suppose a really terrible bug (e.g. an exploitable >> vulnerability) is discovered. Although the latest release is version >> 2.47, it affects every version from 2.12 onwards. Trunk gets quickly >> patched and a new minor version 2.47.1 is released. However, most users >> are still using versions 2.35 and 2.43, and they can't necessarily >> upgrade to 2.47 (e.g. because of some new library dependency that was >> introduced, or some breaking change). What is the correct way of >> handling this in Fossil (or in a DVCS in general)? > > Cherrypick the patch, apply it to the 2.35 and 2.43 branches, and release > the tips of those branches as 2.35.1 and 2.43.1. > > Fossil might be able to do most of this work for you via “fossil merge > --cherrypick”. Try it. > That is exactly what --cherrypick is for. You can see a couple of recent examples of this in the SQLite source tree, where we took a couple bug fixes from trunk and cherrypick-merged them into the branch-3.9 branch to create the recent 3.9.2 release. Example 1: https://www.sqlite.org/src/timeline?c=dab0e607&y=ci You can see that this commit is a cherrypick of the chronologically previous commit that is one trunk. The commands to do this were: fossil update branch-3.9 fossil merge --cherrypick trunk# because at the time db319a03 was head of trunk # test the changes fossil commit When doing the commit, you'll notice that Fossil automatically fills in the commit comment to be the same as the comment on the commit that was cherrypicked. The second example is: https://www.sqlite.org/src/timeline?c=c0c4b6b3&y=ci Which is a cherrypick of an earlier change at https://www.sqlite.org/src/timeline?c=bfea226d&y=ci -- 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] handling backports
On Nov 3, 2015, at 11:48 AM, Eduard wrote: > > Scenario 1: Suppose a really terrible bug (e.g. an exploitable > vulnerability) is discovered. Although the latest release is version > 2.47, it affects every version from 2.12 onwards. Trunk gets quickly > patched and a new minor version 2.47.1 is released. However, most users > are still using versions 2.35 and 2.43, and they can't necessarily > upgrade to 2.47 (e.g. because of some new library dependency that was > introduced, or some breaking change). What is the correct way of > handling this in Fossil (or in a DVCS in general)? Cherrypick the patch, apply it to the 2.35 and 2.43 branches, and release the tips of those branches as 2.35.1 and 2.43.1. Fossil might be able to do most of this work for you via “fossil merge --cherrypick”. Try it. If it doesn’t, I would just diff the change at the tip of trunk into a file, and patch(1) it in by hand on the older feature branches. If you do not already have feature branches for those past versions, Fossil can easily create them on the fly for you. Let’s say that instead of creating feature branches, you just tagged the releases along the trunk instead: f up v2.43 patch -p0 < ~/fix.patch f ci --branch v2.43-security -m 'backported fix [867988a67b]' If you didn’t even tag the releases, then you’d replace “v2.43” in the first command with the checkin ID of the last change made before you released 2.43. And now you know why tagging releases is a good idea. :) > Scenario 2: Consider a repository containing a scientific paper's latex > sources. It is discovered that every single checkin since the very > beginning has a bug that used to cancel out with another bug in latex > itself. However that latex bug has been recently patched, and now every > older version fails to build. The fix itself is just the replacement of > one line that hasn't changed since the bug was introduced. Again, what > is the correct way of handling this? This isn’t a LaTeX issue at all. I see substantially the same problem with #includes on newer versions of GCC. Older versions of the code carry a presumption about the tools used to build the code. You can’t expect 10-year-old sources to build correctly under bleeding-edge tools. Therefore, you either refrain from doing things like checking out older versions of the repo on vastly different machines than were current at the time those checkins were made, or you create branch points from those old versions that are patched to build on current tools. If you’re asking if Fossil supports a way to retroactively patch all past assets checked into the repo so that they build on modern tools, then the answer is, “No, on purpose.” Fossil does not let you edit history, only amend it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
