8 ms·

IIRC people DID give fossil a chance but it turned out it could eat your data. So adoption stopped abruptly. Losing data is very difficult for someone who knows

by plq 10y ago

IIRC people DID give fossil a chance but it turned out it could eat your data. So adoption stopped abruptly. Losing data is very difficult for someone who knows how to use git reflog.

todd8 10y ago
This page, http://www.fossil-scm.org/fossil-v-git/wiki?name=Fossil+versus+Git http://www.fossil-scm.org/fossil-v-git/wiki?name=Fossil+vers..., on the fossil-dcm.org site makes the following claim [emphasis mine]: > Fossil uses a transactional database for local storage, meaning that the repository is protected from corruption even if a crash or power failure occurs in the middle of a commit. Extensive self-checks protect the repository from corruption from bugs. No work has ever been lost due to a software bug in Fossil. I've never heard that Fossil could eat your data. I don't use it now, but I've tried it for a few personal projects and liked it.
minusf 10y ago
[citation needed] ? no software is perfect, but fossil uses sqlite under the hood and is developed by the author of sqlite. a fairly strong data integrity guarantee in my book.
dalke 10y ago
I know about https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04689.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... where a bug in Fossil in trying to figure out what check-in to update to, followed by a user attempt to recover, ended up deleting edited/uncommitted files. Details in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... . Would that have been fixed via reflog? What other failures have there been? To note, many heard about Fossil because of Zed Shaw, who was bitten by the bug, and wrote about leaving Fossil because of the data loss. I wonder, therefore, if your recollection is echoes of that one report. Fossil users pipe up in HN comments, like https://news.ycombinator.com/item?id=12665875 https://news.ycombinator.com/item?id=12665875 from a day ago, https://news.ycombinator.com/item?id=12655740 https://news.ycombinator.com/item?id=12655740 from 3 days ago, and https://news.ycombinator.com/item?id=12622773 https://news.ycombinator.com/item?id=12622773 from a week ago, so there are active users.
- wyoung2 10y ago
  > bug in Fossil in trying to figure out what check-in to update to, followed by a user attempt to recover, ended up deleting edited/uncommitted files Yes, uncommitted changes were lost, which is bad, but not at all what someone would think when you say "Fossil lost data." Also, that particular problem was fixed more than five years ago. > What other failures have there been? I've been using Fossil for my main work repositories for over two years now, and have been monitoring the mailing list for about a year prior to that, and the only things even close to that that I can think of involve crazy user actions that confused Fossil into doing something odd, typically in the UI display only, which are now prevented at the code level. Example: It is possible to fork the trunk by working offline — its autosync feature prevents it from happening when working online, connected to the repo you cloned from — but Fossil now demands that you heal the fork after turning autosync back on, so that you don't end up with multiple active "trunk" tips. After the trunk fork is healed, one branch becomes the "real" trunk, and the other looks like an unnamed branch that's now merged. I'm not aware of any case of committed work being lost by Fossil. In every case where someone has managed to confuse Fossil, it's always been essentially a cosmetic issue, with all of the information necessary to get the repository back to a sane state available in the SQLite DB file. I have personally never run into such a problem. The closest I've ever come to data loss with Fossil was purely due to ignorance. (Briefly, Fossil UI was showing me one thing when I thought it was showing me something else, and since I didn't see what I expected to see, I thought it had lost data. This was purely a newbie misunderstanding.) Compare git: https://xkcd.com/1597/ It's funny because it's truthy.
  - dalke 10y ago
    I essentially agree, which is why I conjectured that plq was recalling incorrectly, based perhaps on second- or third-hand accounts of Shaw's problem. My hope was that plq would clarify either with a pointer or something else more than "IIRC". The only thing I disagree with your assessment is that "ignorance" and "newbie misunderstanding" can sometimes be due to bad design, which is a design bug vs. an implementation bug. In the Shaw case, there was a bug in the code which widened the gap between the user model and how the code actually worked, and that gap did cause data loss, just not in committed data. Also not in a way that could be handled in git with reflog, as plq suggested. This is a more expansive definition of "bug" than software developers, who are often more focused on the implementation than the user interaction model and as XKCD points out are very good at memorizing arcane commands, typically use. Hipp wrote that he might have done the same thing as Shaw, which means that specific case wasn't "purely a newbie misunderstanding." I think that was a humble and magnanimous statement which cut off some of the blame-the-user flamewar that can all too often happen in developer-driven project. As I recall, Shaw noticed this, and thanked Hipp for the way he responded. I've tried to bear it in mind since then.
nomadbyte 10y ago
Indeed, a Fossil repo is actually a SQLite db, one you may as well open and tinker with (at your own risk :). By the same token, it's just as easy to back these repos up, as much as copying the db-file. Or automatically push to a remote. Cron job -- done! Of course, mishaps happen, bugs too. Blaming SCM is easy, blaming no-backup habits, well, that's personal. Fossil does get progressively more potent, I can attest to this on my user experience at least from v1.19 to v1.35. Many convenience features are added, yet core remains stable.
alphapapa 10y ago
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... > To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing.
9mit3t2m9h9a 10y ago
1. Losing uncommitted changes by making two mistakes in a row after non-intuitive behaviour by the VCS is not unheard of in Git. 2. Git is strictly worse than both Fossil and Monotone (two SQLite-based DVCSes I have used) w.r.t. losing _committed_ changes: it doesn't do any sync calls by default, and while their documentation confidently says that fsync is just a waste of time, POSIX guarantees are not enough for safety (ext3 guarantees are enough, btrfs are not — writes to two different files are not guaranteed to be ordered by default, and I have lost commits because of a power failure, and I haven't checked what guarantees ext4 provides there).

by plq 10y ago

IIRC people DID give fossil a chance but it turned out it could eat your data. So adoption stopped abruptly. Losing data is very difficult for someone who knows how to use git reflog.

todd8 10y ago

This page, http://www.fossil-scm.org/fossil-v-git/wiki?name=Fossil+versus+Git http://www.fossil-scm.org/fossil-v-git/wiki?name=Fossil+vers..., on the fossil-dcm.org site makes the following claim [emphasis mine]: > Fossil uses a transactional database for local storage, meaning that the repository is protected from corruption even if a crash or power failure occurs in the middle of a commit. Extensive self-checks protect the repository from corruption from bugs. No work has ever been lost due to a software bug in Fossil. I've never heard that Fossil could eat your data. I don't use it now, but I've tried it for a few personal projects and liked it.

minusf 10y ago

[citation needed] ? no software is perfect, but fossil uses sqlite under the hood and is developed by the author of sqlite. a fairly strong data integrity guarantee in my book.

dalke 10y ago

I know about https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04689.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... where a bug in Fossil in trying to figure out what check-in to update to, followed by a user attempt to recover, ended up deleting edited/uncommitted files. Details in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.or... . Would that have been fixed via reflog? What other failures have there been? To note, many heard about Fossil because of Zed Shaw, who was bitten by the bug, and wrote about leaving Fossil because of the data loss. I wonder, therefore, if your recollection is echoes of that one report. Fossil users pipe up in HN comments, like https://news.ycombinator.com/item?id=12665875 https://news.ycombinator.com/item?id=12665875 from a day ago, https://news.ycombinator.com/item?id=12655740 https://news.ycombinator.com/item?id=12655740 from 3 days ago, and https://news.ycombinator.com/item?id=12622773 https://news.ycombinator.com/item?id=12622773 from a week ago, so there are active users.

wyoung2 10y ago
> bug in Fossil in trying to figure out what check-in to update to, followed by a user attempt to recover, ended up deleting edited/uncommitted files Yes, uncommitted changes were lost, which is bad, but not at all what someone would think when you say "Fossil lost data." Also, that particular problem was fixed more than five years ago. > What other failures have there been? I've been using Fossil for my main work repositories for over two years now, and have been monitoring the mailing list for about a year prior to that, and the only things even close to that that I can think of involve crazy user actions that confused Fossil into doing something odd, typically in the UI display only, which are now prevented at the code level. Example: It is possible to fork the trunk by working offline — its autosync feature prevents it from happening when working online, connected to the repo you cloned from — but Fossil now demands that you heal the fork after turning autosync back on, so that you don't end up with multiple active "trunk" tips. After the trunk fork is healed, one branch becomes the "real" trunk, and the other looks like an unnamed branch that's now merged. I'm not aware of any case of committed work being lost by Fossil. In every case where someone has managed to confuse Fossil, it's always been essentially a cosmetic issue, with all of the information necessary to get the repository back to a sane state available in the SQLite DB file. I have personally never run into such a problem. The closest I've ever come to data loss with Fossil was purely due to ignorance. (Briefly, Fossil UI was showing me one thing when I thought it was showing me something else, and since I didn't see what I expected to see, I thought it had lost data. This was purely a newbie misunderstanding.) Compare git: https://xkcd.com/1597/ It's funny because it's truthy.
- dalke 10y ago
  I essentially agree, which is why I conjectured that plq was recalling incorrectly, based perhaps on second- or third-hand accounts of Shaw's problem. My hope was that plq would clarify either with a pointer or something else more than "IIRC". The only thing I disagree with your assessment is that "ignorance" and "newbie misunderstanding" can sometimes be due to bad design, which is a design bug vs. an implementation bug. In the Shaw case, there was a bug in the code which widened the gap between the user model and how the code actually worked, and that gap did cause data loss, just not in committed data. Also not in a way that could be handled in git with reflog, as plq suggested. This is a more expansive definition of "bug" than software developers, who are often more focused on the implementation than the user interaction model and as XKCD points out are very good at memorizing arcane commands, typically use. Hipp wrote that he might have done the same thing as Shaw, which means that specific case wasn't "purely a newbie misunderstanding." I think that was a humble and magnanimous statement which cut off some of the blame-the-user flamewar that can all too often happen in developer-driven project. As I recall, Shaw noticed this, and thanked Hipp for the way he responded. I've tried to bear it in mind since then.

nomadbyte 10y ago

Indeed, a Fossil repo is actually a SQLite db, one you may as well open and tinker with (at your own risk :). By the same token, it's just as easy to back these repos up, as much as copying the db-file. Or automatically push to a remote. Cron job -- done! Of course, mishaps happen, bugs too. Blaming SCM is easy, blaming no-backup habits, well, that's personal. Fossil does get progressively more potent, I can attest to this on my user experience at least from v1.19 to v1.35. Many convenience features are added, yet core remains stable.

alphapapa 10y ago

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... > To be clear: Fossil should not have malfunctioned. Yet even so, no work was lost as a result of the malfunction. The safety mechanisms built into Fossil did their job and uncommitted changes were preserved. The work was lost when Zed panicked and started entering a bunch of additional commands, in an attempt to recover, without stopping to think through what was happening. In fairness to Zed, I might well have done the same thing.

9mit3t2m9h9a 10y ago

1. Losing uncommitted changes by making two mistakes in a row after non-intuitive behaviour by the VCS is not unheard of in Git. 2. Git is strictly worse than both Fossil and Monotone (two SQLite-based DVCSes I have used) w.r.t. losing _committed_ changes: it doesn't do any sync calls by default, and while their documentation confidently says that fsync is just a waste of time, POSIX guarantees are not enough for safety (ext3 guarantees are enough, btrfs are not — writes to two different files are not guaranteed to be ordered by default, and I have lost commits because of a power failure, and I haven't checked what guarantees ext4 provides there).