Discussion:
Fossil version 1.32
(too old to reply)
Richard Hipp
2015-03-14 14:30:20 UTC
Permalink
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. Please encourage everyone you
know to update to version 1.32.

Please report any problems in the new build to this list. Thanks.
--
D. Richard Hipp
***@sqlite.org
James Turner
2015-03-15 01:45:45 UTC
Permalink
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
Richard Hipp
2015-03-15 02:24:05 UTC
Permalink
Post by James Turner
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
***@sqlite.org
bch
2015-03-15 08:05:42 UTC
Permalink
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
Post by Richard Hipp
Post by James Turner
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
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andy Bradford
2015-03-15 15:37:22 UTC
Permalink
Post by bch
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: 400000005505a755
Ron W
2015-03-16 16:21:45 UTC
Permalink
Post by Andy Bradford
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?
Stephan Beal
2015-03-16 17:41:34 UTC
Permalink
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.
Post by Ron W
Post by Andy Bradford
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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andy Bradford
2015-03-16 18:09:45 UTC
Permalink
Post by Stephan Beal
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: 4000000055071c8b
Richard Hipp
2015-03-16 18:24:12 UTC
Permalink
Post by Andy Bradford
Post by Stephan Beal
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
***@sqlite.org
David Mason
2015-03-17 01:35:51 UTC
Permalink
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
Post by Richard Hipp
Post by Andy Bradford
Post by Stephan Beal
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
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Andy Bradford
2015-03-17 04:59:37 UTC
Permalink
Post by David Mason
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: 400000005507b4dc
Andy Bradford
2015-03-16 18:06:03 UTC
Permalink
Post by Ron W
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?
The server relies on the fact that the first rid in the blob database is
a checkin. I suppose it could be more careful and decide to error if it
discovers that rid=1 is not a checkin.

fossil new currently guarantees that rid=1 is a checkin, but I'm still
not convinced that deconstruct/reconstruct makes this guarantee. So as a
protective measure, the server side of the clone could check and return
an error if it finds that its repository does not have rid=1 and
type=ci.

Or, a new ordering algorithm could be devised. Right now, the order of
artifacts delivered during clone is determined by the sequential
ordering of items in the blob table (which is why rid=1 has to be a
checkin). The cloning sends a clone_seqno, which is basically the last
item out of the list of blobs that has been sent. So a client only needs
to send back the clone_seqno to receive the next batch of artifacts. If
cloning could guarantee that the first artifact sent is a checkin, or
return an error if there are no checkins, this might make it possible to
have repositories that have not the ``initial empty check-in.''

But basically, the onus is currently on whatever populates the blob
table to ensure that the ordering is correct because the clone protocol
just naively takes them in sequential order.

Andy
--
TAI64 timestamp: 4000000055071bac
James Turner
2015-03-16 17:04:30 UTC
Permalink
Post by Richard Hipp
Post by James Turner
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 :)
Post by Richard Hipp
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
James Turner
Baruch Burstein
2015-03-15 08:46:10 UTC
Permalink
Post by Richard Hipp
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ʎ ɟı
Tontyna
2015-03-15 10:29:11 UTC
Permalink
Post by 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>
Continue reading on narkive:
Loading...