Re: [fossil-users] Fossil version 1.32
Does the server fossil know the version number of the client fossil on a clone? Or could it ask? If so, it could do what Andy suggests. ../Dave On 16 March 2015 at 14:24, Richard Hipp d...@sqlite.org wrote: On 3/16/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Keep in mind that if everyone is using Fossil 1.30 or later, we never need to have any check-ins in the repository and the first check-in (if one exists) need not be artifact 1. The code already takes care of all of that. The problem comes up when people try to use Fossil 1.27. And we cannot go reach into peoples machines and fix 1.27. We have to work around whatever it is that 1.27 does. -- 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
Re: [fossil-users] Fossil version 1.32
On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford amb-fos...@bradfords.org wrote: The requirement, specifically, is that the first artifact that the server sends during a clone, must be a checkin, or older Fossil clients will end up in this state. Could the server side be modified to insure the first artifact sent is the first manifest? ___ 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 1.32
On Sat, Mar 14, 2015 at 10:24:05PM -0400, Richard Hipp wrote: On 3/14/15, James Turner ja...@calminferno.net wrote: It appears the actual tarballs were also removed. While I understand the reasoning behind this, this will break automated build systems like ports in OpenBSD for stable releases that may reference older versions of fossil. Is there a reason why the tarballs had to be removed? They are still accessible in the old_builds directory. I could move them back. But I decided to make them hard to get to encourage people to upgrade to a version that doesn't have the Ryerson-student-project-eating bug. *If* you can make a compelling argument to move them back, I might. It's not such a big deal for us, OpenBSD, but I wasn't sure for others if having archives go missing would break builds. Then again I guess it's a good way to force people to upgrade :) -- 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 -- James Turner ___ 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 1.32
wiki-/ticket-only repos might not have a manifest at all. - sent from a mobile device. Please excuse brevity, auto-correction, typos, and top-posting. On Mar 16, 2015 5:21 PM, Ron W ronw.m...@gmail.com wrote: On Sun, Mar 15, 2015 at 11:37 AM, Andy Bradford amb-fos...@bradfords.org wrote: The requirement, specifically, is that the first artifact that the server sends during a clone, must be a checkin, or older Fossil clients will end up in this state. Could the server side be modified to insure the first artifact sent is the first manifest? ___ 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
Re: [fossil-users] Fossil version 1.32
Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Andy -- TAI64 timestamp: 400055071c8b ___ 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 1.32
Thus said David Mason on Mon, 16 Mar 2015 21:35:51 -0400: Does the server fossil know the version number of the client fossil on a clone? Or could it ask? If so, it could do what Andy suggests. Not currently. The client version is not currently exchanged during cloning. The only piece of information that the server is given is the Clone Protocol which is currently 3. Even if the Clone Protocol number is bumped, that still doesn't solve the problem of what happens when someone opens a Fossil that does not have rid=1 and type=ci using Fossil 1.27 (e.g. they used scp to obtain a copy of the Fossil repository). This might require producing an slightly different schema or some incompatible change that would cause the Fossil 1.27 client to refuse to open the Fossil (or continue using it). Andy -- TAI64 timestamp: 40005507b4dc ___ 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 1.32
On 3/16/15, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100: wiki-/ticket-only repos might not have a manifest at all. Then these types of repositories would have to be unclonable by older versions of Fossil. The server would have to refuse the clone request (similar to how it refuses to accept content from clients with an out of date schema). The clone protocol could be modified to include an identifier that allows the server to know if such a repository is incompatible with the client making the request before allowing the clone to proceed. Not sure if this is even possible, but in theory it seems to work. :-) Keep in mind that if everyone is using Fossil 1.30 or later, we never need to have any check-ins in the repository and the first check-in (if one exists) need not be artifact 1. The code already takes care of all of that. The problem comes up when people try to use Fossil 1.27. And we cannot go reach into peoples machines and fix 1.27. We have to work around whatever it is that 1.27 does. -- 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] Fossil version 1.32
Thus said bch on Sun, 15 Mar 2015 01:05:42 -0700: Has the Ryerson Bug be characterised? Yes. Basically, versions of Fossil 1.27 and older, assumed that the first rid in the blob table would always be a checkin. This was true because the first thing fossil new did was to create a bogus checkin with a comment of ``initial empty check-in'', however, there is nothing special about the ``initial empty check-in'' except that it was always the first (e.g. rid=1) in the database. That meant that it would also be first to be offered up during cloning, so all clones would also have a checkin in their local database for rid=1. Then, when this Fossil was open, it would open it beginning with whatever was in rid=1. A change was made to remove the need for the ``initial empty check-in'' which allowed users to make a repository which had the first checkin be their own, however, due to the way checkins are made, this now meant that rid=1 would not be a checkin. So when the older versions of Fossil cloned the repository, it would try to open the newly cloned Fossil with rid=1, but rid=1 was actually no longer a checkin, but another type of artifact (most likely a file). After opening, no files would be seen (clearly because a file manifest does not have files, it has content), and if any commits were made at this time, they would have a P-card which points to the file, not to a checkin. This would result in a broken timeline in the UI. The requirement, specifically, is that the first artifact that the server sends during a clone, must be a checkin, or older Fossil clients will end up in this state. As far as I can tell, this would appear to not have resulted in actual data loss, only some strange problems with the timeline and incorrect manifests. Upgrading to a newer Fossil makes the content available, but there is still the broken timeline and currently Fossil has no way to reconnect the lineage in the timeline (though there is an option planned for altering the parentage). In addition, it's possible that this problem does still exist for repositories that have undergone fossil deconstruct reconstruct operations because as far as I can tell this operation does not guarantee that rid=1 will be a checkin in the newly created repository, however, this is an uncommon procedure. But if reconstruct did place a non-checkin as rid=1, then older clients would not be able to successfully use the clone. Just to be clear, it is still possible to have multiple DAGs in a Fossil using the fossil open --empty. This is allowed because doing so does not create a repository that exhibits the problem described above (because presumably the repository already has the ``initial empty check-in'' which will satisfy the requirement above). Let me know if this needs further clarification. Thanks, Andy -- TAI64 timestamp: 40005505a755 ___ 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 1.32
Has the Ryerson Bug be characterised? Obviously it was confusing, annoying and unintended, but did it turn out to be data losing and/or uncorrectable? Regards -bch On Mar 14, 2015 7:24 PM, Richard Hipp d...@sqlite.org wrote: On 3/14/15, James Turner ja...@calminferno.net wrote: It appears the actual tarballs were also removed. While I understand the reasoning behind this, this will break automated build systems like ports in OpenBSD for stable releases that may reference older versions of fossil. Is there a reason why the tarballs had to be removed? They are still accessible in the old_builds directory. I could move them back. But I decided to make them hard to get to encourage people to upgrade to a version that doesn't have the Ryerson-student-project-eating bug. *If* you can make a compelling argument to move them back, I might. -- 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
Re: [fossil-users] Fossil version 1.32
On Sat, Mar 14, 2015 at 4:30 PM, Richard Hipp d...@sqlite.org wrote: Fossil version 1.32 is now available on the download page: https://www.fossil-scm.org/download.html The new builds all use version numbers in their names instead of dates. All previous builds have been removed from the download page due to the Ryerson student project problem. Can we still have the changelog of the older versions on the download page, even without the links? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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 1.32
Am 15.03.2015 um 09:46 schrieb Baruch Burstein: Can we still have the changelog of the older versions on the download page, even without the links? And/or a link to older versions like on http://www.sqlite.org/releaselog/3_8_8_3.html ___ 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 1.32
On 3/14/15, James Turner ja...@calminferno.net wrote: It appears the actual tarballs were also removed. While I understand the reasoning behind this, this will break automated build systems like ports in OpenBSD for stable releases that may reference older versions of fossil. Is there a reason why the tarballs had to be removed? They are still accessible in the old_builds directory. I could move them back. But I decided to make them hard to get to encourage people to upgrade to a version that doesn't have the Ryerson-student-project-eating bug. *If* you can make a compelling argument to move them back, I might. -- 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] Fossil version 1.32
It appears the actual tarballs were also removed. While I understand the reasoning behind this, this will break automated build systems like ports in OpenBSD for stable releases that may reference older versions of fossil. Is there a reason why the tarballs had to be removed? -- James Turner ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
