16 ms·

Fossil: A decentralized version control, bug tracking, and wiki software

227 points by Rexxar 10y ago

qwertyuiop924 10y ago
Fossil is really cool. It never really caught on, which is kind of a shame. OTOH, it's competing with git, a very well-designed piece of software with ungodly marketing (and a terrible UI, and it was so well designed because McVoy's various projects had already made many of the mistakes that Git didn't, although it avoided some of Git's mistakes, so Linus had something to work off of. But that's not the point).
- yitchelle 10y ago
  > with ungodly marketing Was the the marketing of git basically due to the fact that Linus created it?
  - adambrenecki 10y ago
    I think it had more to do with GitHub than anything else. In GitHub's early days, they put a lot of effort into marketing Git (e.g. the now defunct "Git Is Better Than X" website), because they needed people to use it in order to use GitHub.
    - antod 10y ago
      I reckon it was a combination of Github and Rails being early adopters at the peak growth of their hype cycle. In the early days of Github it seemed like most of the projects there were Ruby based (Rails users overflowing).
  - JoshTriplett 10y ago
    Developer word-of-mouth in general, combined with the massive network effects of a version control system. Once you use a VCS because software you work on uses it, if you want to start your own project, you tend to use what you know.
  - wangchow 10y ago
    Git was designed for the Linux kernel source which everyone using android or another Linux distro is interested in. That helps a lot because if it can handle that project surely it can handle any other codebase.
    - solipsism 10y ago
      Not any other codebase. Codebases with huge and often-changing binaries (e.g. images or 3d models), for example, were troublesome for git, at least historically. The Linux kernel isn't big in all ways.
- 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.
- pampa 10y ago
  People keep talking about git's terrible UI. I dont get it, anybody who had used subversion or cvs before could grasp the basics in like 5 minutes and have much better user experience.
  - em3rgent0rdr 10y ago
    Just because A is better than B doesn't mean that A is good.
    - pampa 10y ago
      Back in the day using CVS, and subversion later was a constant struggle. Before switching to git i used darcs for several years and tried mercurial. Git was clearly better than any of them. So, how can you tell that git is no good, if it is the best of the tools available?
      - jack9 10y ago
        > subversion later was a constant struggle The only struggle about svn is branching (copy the whole thing) and merging was more frequent. There were many CVS systems, which I worked on, where there was no way to track who made what change in a day.
      - lucideer 10y ago
        You switched from using "was" in your first paragraph to "is" in your second. There are certainly more competitors to Git today than there were then.
        isxek 10y ago
        Are there really more? Some similar projects like Monotone and Bazaar are no longer being actively/regularly developed IIRC, and the number of hosting services for something as well-known as Mercurial has been dwindling.
        10y ago
phantom_oracle 10y ago
Link to comparison: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
gaxun 10y ago
I'm reading the page on how the distributed bug tracking works. I've heard of Fossil before but never dug too deeply. > But if a timestamp on a ticket change artifact is off by months or years, it can seriously confuse the replay algorithm for determining the current ticket state. I understand the simplicity of merging all the ticket comments by timestamp, but couldn't they at least include a reference to one or more recent comments to help establish order when clocks are off? Still wouldn't avoid intentional bad actors, but there are bound to be people with misconfigured clocks. If I'm working on a Fossil repository and I want to see what bugs everyone else has reported, where do I go to get a list of other copies of the repository so I can query them for new bug reports? Is there some kind of tracker that lists all the people currently publishing the same Fossil repository, so I can connect to each one and ask for updates? I wrote a post [0] on my site about this concept recently. It's not really polished, I think the thoughts were incomplete. It was written in the context of git due to its ubiquity these days, but the concept should apply the same to other DVCS. I know I'm full of a lot of questions and few answers, but questions help me learn. [0] https://www.gaxun.net/ideas/git-announce/ https://www.gaxun.net/ideas/git-announce/
- noobermin 10y ago
  >I've heard of Fossil before but never dug too deeply. Pun not intended?
- wyoung2 10y ago
  > there are bound to be people with misconfigured clocks. Let's step back a bit here, and realize that ticket tracking is typically one of the things you restrict access to in a Fossil repository. You're either running a private instance and have the whole repo locked down, or you're running a public instance and at least require a valid login before users are allowed to post tickets. The SQLite.org repo doesn't even allow normal users to post tickets; that feature is restricted to the core development team, with public-originating items going into the ticket tracker only after being discussed on the mailing list first. (This policy also eliminates ticket spam.) Therefore, the number of users that can confuse Fossil this way is small, and the Fossil server admin probably knows how to contact all of them. Given that, the only way you're likely to confuse Fossil via this weakness is to have two people with clocks maybe a large fraction of an hour off both modifying the same ticket within an hour's span, so that the person with the bad clock appears to be making comments before the comments from other users. (Or vice versa if the clock error is in the future direction.) So, we have an error case that can only happen among a small number of users, and only when someone isn't using NTP like they ought to, and then only when we have multiple users modifying a particular ticket in a small time window, and when it happens, it only causes a bit of web UI weirdness, not data corruption. There's your answer, then: why spend much time fixing an extremely rare case with such minor consequences? If it really bothers you, the Fossil project regularly accepts outside contribution patches. > where do I go to get a list of other copies of the repository so I can query them for new bug reports? You don't have to. Fossil syncs all artifacts back to the repo it cloned from, not just code artifacts. This includes not only tickets, but also wiki articles, etc. The only weakness here is that Fossil's autosync feature doesn't happen on certain types of updates, including ticket changes, so you have two choices: manually say "fossil sync" to push ticket changes to the central repo, or wait until the next code commit, which will gather up the ticket changes and send those along with the code commit. I don't know why Fossil doesn't autosync local ticket changes, but I'm sure it's purely a matter of development time and will, not a designed-in weakness. If you want remote fossils to autosync their local ticket changes, it should be easy to add the feature. > Is there some kind of tracker that lists all the people currently publishing the same Fossil repository In the context of your blog post, Fossil generally isn't run in the git "just fork me" mode of operation. It can run that way, but it's much more commonly used in the central-plus-clones model, where there is a canonical central repository and a working clone on each developer's machine. This mode is encouraged by the Fossil autosync feature being turned on by default, which means each local checkin also syncs to the central repo. You can turn autosync off, in which case Fossil works more like git, where a clone is allowed to go off on its own tangent relative to the repo it cloned from. However, that buys you many of the problems of Git relative to Fossil, such as that merging can be a pain. Autosync greatly increases the chance that any given commit will apply cleanly.
X86BSD 10y ago
I absolutely love Fossil. I'm really glad to see it show up on HN. I've never heard of it eating data before.
- hvidgaard 10y ago
  It hasn't. There was a bug that would delete every file except the modified ones. If you panic there, you could end up deleting your modifications because you tell fossil to. It gained quite a bit of attention because Zed A. Shaw was bitten by it. Nevermind he didn't make a single commit for 3 days, or that he panicked, or that he didn't even make a simple "backup this folder so anything I do doesn't mess it up" as is standard with all other DVCS when something goes wrong. Fossil is fine in this regard, but a rebase function would be welcome.
Karupan 10y ago
I used Fossil for about 4 months on a project. Found it easier than git in terms of CLI usability. The inbuilt UI, although not polished, is pretty usable. And the entire project is pretty much a single SQLite file. It definitely hasn't gotten the attention it deserves. P.S: It's primary author is known for another piece of software that runs pretty much everywhere - SQLite!
- wyoung2 10y ago
  > The inbuilt UI, although not polished If your experience was more than about half a year old, you might want to look at it again. The default skin changed recently to one that is much more of a modern web UI. It is easy to switch the skin on an existing repository or to customize it to behave the way you like. Fossil currently ships with 10 distinct skins, by my count.
  - xwattt 10y ago
    > skin The problem of fossil UI is not a skin. Why that annoying commit hashes are so big? Do you really read them first? Take a look at github UI: every button and label have meaningful place and polished. And that is the problem of most github clones - they forgot to hire a designer.
    - wyoung2 10y ago
      > Why that annoying commit hashes are so big? In most places, Fossil shows an abbreviated form of the hash, typically 8-10 characters since Fossil, like Git, will accept any unique prefix of an artifact hash to refer to that artifact. Here is a GitHub commit page: https://github.com/aioutecism/amVim-for-VSCode/commits/master and here is a Fossil timeline page, which serves much the same purpose: http://fossil-scm.org/index.html/timeline In the fossil case, the hashes are one character longer, and enclosed in square brackets instead of a roundrect. This is a serious complaint? > Do you really read them first? No, you ignore them completely until you need to refer to one, and then you copy-paste it, just like with Git. > every button and label have meaningful place and polished Which button or label in the default Fossil skin is not in a meaningful place, and which shows a lack of polish? Be specific. > they forgot to hire a designer. I'm pretty sure the differences between the two stem not from forgetfulness but from the fact that GitHub, Inc. employs 608 people, is closed source, and has a revenue model, whereas Fossil is a side project of a company that's probably 1/100 that size and grows mainly by open source user code contributions.
PeCaN 10y ago
I use fossil for all my personal projects. It's absolutely a pleasure to use. Not much more to say about it, it's a tool that's easy to use and gets the job done. Easy to export to a git repo too, e.g. to mirror to GitHub (which I do).
- em3rgent0rdr 10y ago
  could you provide your code/instructions for mirroring to GitHub? I presume you mirror on every local commit?
  - PeCaN 10y ago
    Nothing fancy, I just do fossil export --git repo.fossil | git fast-import manually every now and then. I could set up a fossil hook to do it, but I haven't quite bothered to yet.
  - nomadbyte 10y ago
    IMHO, no need to actually mirror. You may simply keep the same project under both Git and Fossil, just add ".fslckout" and "_FOSSIL_" to your .gitignore. 1) Setup Git repo on GitHub. 2) Clone the Git repo. 3) Create local Fossil repo. 4) Add the cloned project to Fossil repo. 5) Work with Fossil. 6) Add/commit completed features to Git. 7) Push to GitHub. 8) Pull/Update respectively. A bit of overhead, but for personal projects easy to get used to.
LVB 10y ago
I like a lot about Fossil and moved many projects into it for a while. What I eventually couldn't tolerate was the lack of rebase (and history rewriting in general). There are extensive debates going back years on the Fossil mailing list about the topic, but ultimately the authors were pretty firm that rebase/rewriting history is bad and they didn't want to support it. My local workflow uses commit rewriting a lot in order to keep a useful history. I commit like crazy and then squash/reorder/rebase to make a nice logical history (http://gitup.co http://gitup.co is awesome for this on OSX, BTW). I couldn't do this, at least at the time, with Fossil, and ended up with piles of not-very-useful commits.
- cm3 10y ago
  Yeah, git doesn't restrict you in that regard and supports both workflows, which may differ from project to project. Mercurial has a nice improved version of this, where it's safe to rewrite locally but you're not allowed to rewrite public history. I think that's a smart compromise, although if the project you're working on has the concept of patch queues, like the linux kernel and others, then mutable history to maintain patch queues is a feature, which in fact had been supported by a few extensions before the new mercurial rebase implementation landed.
  - petre 10y ago
    Fossil also has private branches.
    - cm3 10y ago
      Can you rewrite history in those?
      - petre 10y ago
        No, you cannot rewrite history at all in fossil. But you can commit repeatedly to the private branch and when finished merge all the changes into a public branch. It will look like a single commit. https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki
SwellJoe 10y ago
Fossil has always seemed really cool, but I don't know if having everything in one big dependency bundle is actually a good thing. For a variety of reasons, there will never be a consensus on the right issue tracker and wiki for every project (and Fossil's implementation is necessarily quite lightweight and light on capabilities compared to the big guys), so having them all tied together in an integrated whole is probably one reason Fossil as a revision control system didn't take off. It caused bunch of people to select out because they were thinking, "Well, we can't use this tracker or this wiki, because we need X and Y from our tracker/wiki. This system isn't for us." That said, I'd love to see these features built as add-ons to git; it wouldn't be particularly difficult (no more difficult than developing a ticket tracker or a wiki independent of git). Then again, I'm uncomfortable with the repository dragging in lots of big stuff like screenshots and diagrams and such, which are very common for bug trackers and wikis and less common for code repositories (and something git historically didn't do well, anyway). Perhaps having a separate git repo for each piece (source, bugs, wiki) and a convention of including links to them inside of special hidden file (like .gitignore) would be the right thing. But, then we don't have the issues and docs following the code around very closely, which gives up some of the positives. But, out of the box, Fossil is a really nice looking system. If I weren't working with other people who already know git (which describes almost everyone everywhere), I'd probably give it a go. But, I am, so I won't.
- wyoung2 10y ago
  I hear what you're saying, but I don't think someone evaluating Fossil should say things like, "We've always been a Bugzilla/MediaWiki/whatever shop, so we won't use tools that don't integrate with that." Instead, they should evaluate whether Fossil's version of those features provides what they need. Specifically regarding the ticket tracker, someone evaluating Fossil should realize that it is really flexible: https://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki http://www.sqliteconcepts.org/THManual.pdf If you don't like what Fossil's ticket system does out of the box, you can probably make it do what you need with a small amount of customization. I don't mean to be rude or cast aspersions on you, but there's a lot of FUD like this surrounding Fossil. People look at multicolumn feature lists and see this one weird feature in one of the non-Fossil columns that has a check where Fossil doesn't and write Fossil off because they think they might need that feature. This kind of thinking is why there are so many 4x4 SUVs in the grocery store parking lot. The simple fact is that there are a whole lot more relatively small software development teams than there are huge teams that really need a large fraction of the features in the large competing software packages. Realize that I'm saying this about a DVCS that was designed to fit the needs of SQLite.org. If your team, code base, and community isn't larger than that of SQLite.org, it's "small" in this context, and can probably work happily within Fossil's limitations. Just as you won't be putting your Jeep Grand Cherokee in 4-Lo to get out of the parking lot, you probably don't actually need everything that, say, Bugzilla provides over Fossil's ticketing system. Now, if you're comparing Fossil ticketing to Redmine + the Scrum dashboard plugin, and your project management is currently based on that workflow, that's a horse of a different color. But then, there's nothing preventing you from ignoring Fossil's ticketing feature and continuing to use your existing project management system.
antman 10y ago
nitpick [0] uses your git branches for bug tracking, and has a very easily customizable interface [1] [0] https://github.com/tst2005/nitpick https://github.com/tst2005/nitpick [1] http://travisbrown.ca/projects/nitpick/docs/nitpick.html http://travisbrown.ca/projects/nitpick/docs/nitpick.html
- chriswarbo 10y ago
  Thanks, I've been looking for a distributed bug tracker (for use with git) for a while. bugseverywhere seems unmaintained, and all of the other info I could find was about abandoned projects from 2011. I'll give nitpick a go :)
starseeker 10y ago
I'm quite intrigued by the libfossil project (http://fossil.wanderinghorse.net/repos/libfossil http://fossil.wanderinghorse.net/repos/libfossil) which attempts to make the core fossil VCS abilities available as a library. To the best of my understanding this is and will remain a "spin-off" project of the main fossil project, but it looks like as of August 2016 there is still active work on it. The combination of the BSD license and a self-contained C library in the style of sqlite that offers VCS capabilities app developers could build into their applications is extremely enticing. libgit2 (https://libgit2.github.com/ https://libgit2.github.com/) may have matured enough to be viable for that use case if one is comfortable with GPLv2 plus linking exception, but the sqlite-style include one header, build one C file and you're done integration is really really nice.
smegel 10y ago
Hell of a thing to write something like that in C.
- bch 10y ago
  Ostensibly, fossil is not written in C, but a high level language - SQL.
  - deleted 10y ago
    [deleted]
  - wyoung2 10y ago
    There is about 94 kSLOC of C code in Fossil at the moment, not counting SQLite itself, according to SLOCCount. SQLite more than doubles that line count. By that measure alone, about half of Fossil is "SQL", in the sense that more than half of the code merely manages the various DBs. (A Fossil workspace consists of three SQLite DBs: the actual repo DB plus two machine-specific DBs, one local to the project and one global to the user login.) There is a whole lot of embedded SQL among that C code. Simply counting the number of lines containing the 5 most common SQL statements: SELECT: 2069 INSERT: 583 DELETE: 492 UPDATE: 410 REPLACE: 122 That doesn't mean the total number of embedded SQL statements is the total of those 5 numbers, as some of that will be compound statements using two or more of the above keywords. Fossil uses some of the most complex SQL I've ever seen outside of http://thedailywtf.com/ http://thedailywtf.com/ So, while Fossil does rely very heavily on SQL, I wouldn't say it is "written in SQL." It merely delegates as much as is sensible to SQL, in the same way that a fair bit of the Fossil web user interface uses Javascript rather than call back to the Fossil binary on the server via POST and such to fetch an updated page.
- deleted 10y ago
  [deleted]
rwbt 10y ago
Love fossil. I use it for all my projects. Simple and easy to learn CLI (unlike some other popular DVCS) and the built-in issue tracker/wiki is very helpful. For indie devs or small teams fossil 'just works'.
SQLite 10y ago
Original author of Fossil here, with two comments: (1) Fossil was created for the single purpose of supporting SQLite development, a mission at which it has succeeded spectacularly. Fossil is therefore a success story, irregardless of its mind-share relative to Git. That thousands of other developers also find Fossil useful on their own project is just gravy. I am not concerned that Fossil has not (yet) become the "one true and great DVCS". My intent is to continue personally supporting and maintaining Fossil for at least three more decades. (2) Git people: Please steal ideas and code from Fossil. This is not about winning and losing; it is about providing the best possible tools. Fossil has a number features which are missing from Git but which could be easily added to Git and would enhance the Git-user experience. I'm not talking about the philosophical differences between Fossil and Git (which I recognize that Git is unlikely to ever change) but rather specific UI features such as "fossil all" or "fossil ui" or "fossil undo" or the ability to view the ancestors of check-ins. Fossil is 2-clause BSD, so you do not even have to acknowledge where you stole the code from. Do it for your users, please.
- mysterydip 10y ago
  Never heard of it before, but I'm grateful to hear about it! My projects were always small enough that a traditional version control system wasn't worth the time to set up. Just keep an archive of each day's progress in a folder and call it done. With my latest project, I'm maintaining multiple splits of the codebase for different platform-specific features, and sharing the code with a team member. I was about to bite the bullet and start installing cvs or git in a VM and going through the learning curve, but this seems right up my alley and the kind of system I'd mesh with well. Thanks!
  - lucaspiller 10y ago
    > My projects were always small enough that a traditional version control system wasn't worth the time to set up There's no such thing as too small: I use Git for everything, including small scripts I may never use again. The setup is "mkdir fooscript && cd fooscript && git init". Plus using GitLuBucket means free backups.
nomadbyte 10y ago
Version control debates, why?? I think everyone agreed that having an SCM on a project is a must. Everyone most likely is using some SCM already, often-times the choice is made by someone else upstairs or in the history. Git, bzr, hg, svn, TFS (ahem) -- you've just got to use what you've got. HOWEVER, you may just as well use an SCM that is more __optimal__ for your development style, say, frequent commits, branching, stashes, private branches and then just pump the completed stages into "official" SCM -- kind of layering the version control. You can install Git or bzr etc. just for yourself? Good!, but not everyone may have such a policy. Fossil does not require installation, it's a self-contained executable, you may just as well build it from source and use it in your account. Just as simply, the same project directory may be tracked by Fossil in addition to the whatever is the "official" SCM, the only file it places in working dir is ".fslckout". I think, there's really no need to debate and pit SCMs against each other -- just use what works for you, your project, well, what fits in your own memory (it's true, Fossil command and options set is very compact, yet potent -- check it out!)
rcarmo 10y ago
I've been using Fossil on and off throughout the years, and find it to be a very nice all-in-one solution for personal projects. Collaborating, however, is an issue due to the prevalence of git (it was a bit easier in the Mercurial days because hg users were used to coexisting with something else). The biggest advantage for me is having a single file as the repo. Makes it much easier to archive stuff.
jslakro 10y ago
What about GitTorrent? https://github.com/cjb/gittorrent https://github.com/cjb/gittorrent
nomadbyte 10y ago
Perhaps another factor for minor popularity of Fossil SCM is a lack of plugins for major IDEs. I don't believe this should be such an obstacle, as most plugins implement only a part of SCM client features, thus asking you to resort to command-line for certain functions. Still, for a lot of developers the expected interaction with "everything" is through IDE. There seems to be a Git or SVN plugin for every possible IDE, yet Fossil lags in that department. JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin. We faced this with our Qt projects, and went on to develop a Fossil SCM plugin for QtCreator: https://github.com/nomadbyte/qtcreator-plugin-fossil https://github.com/nomadbyte/qtcreator-plugin-fossil Not that availability of plugins has to be such a big deal for a SCM adoption, but sure this helps a lot to increase any SCM's visibility and accessibility. In case of Fossil this probably will have to be another community effort.

227 points by Rexxar 10y ago

Fossil is really cool. It never really caught on, which is kind of a shame. OTOH, it's competing with git, a very well-designed piece of software with ungodly marketing (and a terrible UI, and it was so well designed because McVoy's various projects had already made many of the mistakes that Git didn't, although it avoided some of Git's mistakes, so Linus had something to work off of. But that's not the point).

yitchelle 10y ago
> with ungodly marketing Was the the marketing of git basically due to the fact that Linus created it?
- adambrenecki 10y ago
  I think it had more to do with GitHub than anything else. In GitHub's early days, they put a lot of effort into marketing Git (e.g. the now defunct "Git Is Better Than X" website), because they needed people to use it in order to use GitHub.
  - antod 10y ago
    I reckon it was a combination of Github and Rails being early adopters at the peak growth of their hype cycle. In the early days of Github it seemed like most of the projects there were Ruby based (Rails users overflowing).
- JoshTriplett 10y ago
  Developer word-of-mouth in general, combined with the massive network effects of a version control system. Once you use a VCS because software you work on uses it, if you want to start your own project, you tend to use what you know.
- wangchow 10y ago
  Git was designed for the Linux kernel source which everyone using android or another Linux distro is interested in. That helps a lot because if it can handle that project surely it can handle any other codebase.
  - solipsism 10y ago
    Not any other codebase. Codebases with huge and often-changing binaries (e.g. images or 3d models), for example, were troublesome for git, at least historically. The Linux kernel isn't big in all ways.
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.
pampa 10y ago
People keep talking about git's terrible UI. I dont get it, anybody who had used subversion or cvs before could grasp the basics in like 5 minutes and have much better user experience.
- em3rgent0rdr 10y ago
  Just because A is better than B doesn't mean that A is good.
  - pampa 10y ago
    Back in the day using CVS, and subversion later was a constant struggle. Before switching to git i used darcs for several years and tried mercurial. Git was clearly better than any of them. So, how can you tell that git is no good, if it is the best of the tools available?
    - jack9 10y ago
      > subversion later was a constant struggle The only struggle about svn is branching (copy the whole thing) and merging was more frequent. There were many CVS systems, which I worked on, where there was no way to track who made what change in a day.
    - lucideer 10y ago
      You switched from using "was" in your first paragraph to "is" in your second. There are certainly more competitors to Git today than there were then.
      - isxek 10y ago
        Are there really more? Some similar projects like Monotone and Bazaar are no longer being actively/regularly developed IIRC, and the number of hosting services for something as well-known as Mercurial has been dwindling.
        10y ago

phantom_oracle 10y ago

Link to comparison: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...

gaxun 10y ago

I'm reading the page on how the distributed bug tracking works. I've heard of Fossil before but never dug too deeply. > But if a timestamp on a ticket change artifact is off by months or years, it can seriously confuse the replay algorithm for determining the current ticket state. I understand the simplicity of merging all the ticket comments by timestamp, but couldn't they at least include a reference to one or more recent comments to help establish order when clocks are off? Still wouldn't avoid intentional bad actors, but there are bound to be people with misconfigured clocks. If I'm working on a Fossil repository and I want to see what bugs everyone else has reported, where do I go to get a list of other copies of the repository so I can query them for new bug reports? Is there some kind of tracker that lists all the people currently publishing the same Fossil repository, so I can connect to each one and ask for updates? I wrote a post [0] on my site about this concept recently. It's not really polished, I think the thoughts were incomplete. It was written in the context of git due to its ubiquity these days, but the concept should apply the same to other DVCS. I know I'm full of a lot of questions and few answers, but questions help me learn. [0] https://www.gaxun.net/ideas/git-announce/ https://www.gaxun.net/ideas/git-announce/

noobermin 10y ago
>I've heard of Fossil before but never dug too deeply. Pun not intended?
wyoung2 10y ago
> there are bound to be people with misconfigured clocks. Let's step back a bit here, and realize that ticket tracking is typically one of the things you restrict access to in a Fossil repository. You're either running a private instance and have the whole repo locked down, or you're running a public instance and at least require a valid login before users are allowed to post tickets. The SQLite.org repo doesn't even allow normal users to post tickets; that feature is restricted to the core development team, with public-originating items going into the ticket tracker only after being discussed on the mailing list first. (This policy also eliminates ticket spam.) Therefore, the number of users that can confuse Fossil this way is small, and the Fossil server admin probably knows how to contact all of them. Given that, the only way you're likely to confuse Fossil via this weakness is to have two people with clocks maybe a large fraction of an hour off both modifying the same ticket within an hour's span, so that the person with the bad clock appears to be making comments before the comments from other users. (Or vice versa if the clock error is in the future direction.) So, we have an error case that can only happen among a small number of users, and only when someone isn't using NTP like they ought to, and then only when we have multiple users modifying a particular ticket in a small time window, and when it happens, it only causes a bit of web UI weirdness, not data corruption. There's your answer, then: why spend much time fixing an extremely rare case with such minor consequences? If it really bothers you, the Fossil project regularly accepts outside contribution patches. > where do I go to get a list of other copies of the repository so I can query them for new bug reports? You don't have to. Fossil syncs all artifacts back to the repo it cloned from, not just code artifacts. This includes not only tickets, but also wiki articles, etc. The only weakness here is that Fossil's autosync feature doesn't happen on certain types of updates, including ticket changes, so you have two choices: manually say "fossil sync" to push ticket changes to the central repo, or wait until the next code commit, which will gather up the ticket changes and send those along with the code commit. I don't know why Fossil doesn't autosync local ticket changes, but I'm sure it's purely a matter of development time and will, not a designed-in weakness. If you want remote fossils to autosync their local ticket changes, it should be easy to add the feature. > Is there some kind of tracker that lists all the people currently publishing the same Fossil repository In the context of your blog post, Fossil generally isn't run in the git "just fork me" mode of operation. It can run that way, but it's much more commonly used in the central-plus-clones model, where there is a canonical central repository and a working clone on each developer's machine. This mode is encouraged by the Fossil autosync feature being turned on by default, which means each local checkin also syncs to the central repo. You can turn autosync off, in which case Fossil works more like git, where a clone is allowed to go off on its own tangent relative to the repo it cloned from. However, that buys you many of the problems of Git relative to Fossil, such as that merging can be a pain. Autosync greatly increases the chance that any given commit will apply cleanly.

X86BSD 10y ago

I absolutely love Fossil. I'm really glad to see it show up on HN. I've never heard of it eating data before.

hvidgaard 10y ago
It hasn't. There was a bug that would delete every file except the modified ones. If you panic there, you could end up deleting your modifications because you tell fossil to. It gained quite a bit of attention because Zed A. Shaw was bitten by it. Nevermind he didn't make a single commit for 3 days, or that he panicked, or that he didn't even make a simple "backup this folder so anything I do doesn't mess it up" as is standard with all other DVCS when something goes wrong. Fossil is fine in this regard, but a rebase function would be welcome.

Karupan 10y ago

I used Fossil for about 4 months on a project. Found it easier than git in terms of CLI usability. The inbuilt UI, although not polished, is pretty usable. And the entire project is pretty much a single SQLite file. It definitely hasn't gotten the attention it deserves. P.S: It's primary author is known for another piece of software that runs pretty much everywhere - SQLite!

wyoung2 10y ago
> The inbuilt UI, although not polished If your experience was more than about half a year old, you might want to look at it again. The default skin changed recently to one that is much more of a modern web UI. It is easy to switch the skin on an existing repository or to customize it to behave the way you like. Fossil currently ships with 10 distinct skins, by my count.
- xwattt 10y ago
  > skin The problem of fossil UI is not a skin. Why that annoying commit hashes are so big? Do you really read them first? Take a look at github UI: every button and label have meaningful place and polished. And that is the problem of most github clones - they forgot to hire a designer.
  - wyoung2 10y ago
    > Why that annoying commit hashes are so big? In most places, Fossil shows an abbreviated form of the hash, typically 8-10 characters since Fossil, like Git, will accept any unique prefix of an artifact hash to refer to that artifact. Here is a GitHub commit page: https://github.com/aioutecism/amVim-for-VSCode/commits/master and here is a Fossil timeline page, which serves much the same purpose: http://fossil-scm.org/index.html/timeline In the fossil case, the hashes are one character longer, and enclosed in square brackets instead of a roundrect. This is a serious complaint? > Do you really read them first? No, you ignore them completely until you need to refer to one, and then you copy-paste it, just like with Git. > every button and label have meaningful place and polished Which button or label in the default Fossil skin is not in a meaningful place, and which shows a lack of polish? Be specific. > they forgot to hire a designer. I'm pretty sure the differences between the two stem not from forgetfulness but from the fact that GitHub, Inc. employs 608 people, is closed source, and has a revenue model, whereas Fossil is a side project of a company that's probably 1/100 that size and grows mainly by open source user code contributions.

PeCaN 10y ago

I use fossil for all my personal projects. It's absolutely a pleasure to use. Not much more to say about it, it's a tool that's easy to use and gets the job done. Easy to export to a git repo too, e.g. to mirror to GitHub (which I do).

em3rgent0rdr 10y ago
could you provide your code/instructions for mirroring to GitHub? I presume you mirror on every local commit?
- PeCaN 10y ago
  Nothing fancy, I just do fossil export --git repo.fossil | git fast-import manually every now and then. I could set up a fossil hook to do it, but I haven't quite bothered to yet.
- nomadbyte 10y ago
  IMHO, no need to actually mirror. You may simply keep the same project under both Git and Fossil, just add ".fslckout" and "_FOSSIL_" to your .gitignore. 1) Setup Git repo on GitHub. 2) Clone the Git repo. 3) Create local Fossil repo. 4) Add the cloned project to Fossil repo. 5) Work with Fossil. 6) Add/commit completed features to Git. 7) Push to GitHub. 8) Pull/Update respectively. A bit of overhead, but for personal projects easy to get used to.

LVB 10y ago

I like a lot about Fossil and moved many projects into it for a while. What I eventually couldn't tolerate was the lack of rebase (and history rewriting in general). There are extensive debates going back years on the Fossil mailing list about the topic, but ultimately the authors were pretty firm that rebase/rewriting history is bad and they didn't want to support it. My local workflow uses commit rewriting a lot in order to keep a useful history. I commit like crazy and then squash/reorder/rebase to make a nice logical history (http://gitup.co http://gitup.co is awesome for this on OSX, BTW). I couldn't do this, at least at the time, with Fossil, and ended up with piles of not-very-useful commits.

cm3 10y ago
Yeah, git doesn't restrict you in that regard and supports both workflows, which may differ from project to project. Mercurial has a nice improved version of this, where it's safe to rewrite locally but you're not allowed to rewrite public history. I think that's a smart compromise, although if the project you're working on has the concept of patch queues, like the linux kernel and others, then mutable history to maintain patch queues is a feature, which in fact had been supported by a few extensions before the new mercurial rebase implementation landed.
- petre 10y ago
  Fossil also has private branches.
  - cm3 10y ago
    Can you rewrite history in those?
    - petre 10y ago
      No, you cannot rewrite history at all in fossil. But you can commit repeatedly to the private branch and when finished merge all the changes into a public branch. It will look like a single commit. https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/private.wiki

SwellJoe 10y ago

Fossil has always seemed really cool, but I don't know if having everything in one big dependency bundle is actually a good thing. For a variety of reasons, there will never be a consensus on the right issue tracker and wiki for every project (and Fossil's implementation is necessarily quite lightweight and light on capabilities compared to the big guys), so having them all tied together in an integrated whole is probably one reason Fossil as a revision control system didn't take off. It caused bunch of people to select out because they were thinking, "Well, we can't use this tracker or this wiki, because we need X and Y from our tracker/wiki. This system isn't for us." That said, I'd love to see these features built as add-ons to git; it wouldn't be particularly difficult (no more difficult than developing a ticket tracker or a wiki independent of git). Then again, I'm uncomfortable with the repository dragging in lots of big stuff like screenshots and diagrams and such, which are very common for bug trackers and wikis and less common for code repositories (and something git historically didn't do well, anyway). Perhaps having a separate git repo for each piece (source, bugs, wiki) and a convention of including links to them inside of special hidden file (like .gitignore) would be the right thing. But, then we don't have the issues and docs following the code around very closely, which gives up some of the positives. But, out of the box, Fossil is a really nice looking system. If I weren't working with other people who already know git (which describes almost everyone everywhere), I'd probably give it a go. But, I am, so I won't.

wyoung2 10y ago
I hear what you're saying, but I don't think someone evaluating Fossil should say things like, "We've always been a Bugzilla/MediaWiki/whatever shop, so we won't use tools that don't integrate with that." Instead, they should evaluate whether Fossil's version of those features provides what they need. Specifically regarding the ticket tracker, someone evaluating Fossil should realize that it is really flexible: https://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki http://www.sqliteconcepts.org/THManual.pdf If you don't like what Fossil's ticket system does out of the box, you can probably make it do what you need with a small amount of customization. I don't mean to be rude or cast aspersions on you, but there's a lot of FUD like this surrounding Fossil. People look at multicolumn feature lists and see this one weird feature in one of the non-Fossil columns that has a check where Fossil doesn't and write Fossil off because they think they might need that feature. This kind of thinking is why there are so many 4x4 SUVs in the grocery store parking lot. The simple fact is that there are a whole lot more relatively small software development teams than there are huge teams that really need a large fraction of the features in the large competing software packages. Realize that I'm saying this about a DVCS that was designed to fit the needs of SQLite.org. If your team, code base, and community isn't larger than that of SQLite.org, it's "small" in this context, and can probably work happily within Fossil's limitations. Just as you won't be putting your Jeep Grand Cherokee in 4-Lo to get out of the parking lot, you probably don't actually need everything that, say, Bugzilla provides over Fossil's ticketing system. Now, if you're comparing Fossil ticketing to Redmine + the Scrum dashboard plugin, and your project management is currently based on that workflow, that's a horse of a different color. But then, there's nothing preventing you from ignoring Fossil's ticketing feature and continuing to use your existing project management system.

antman 10y ago

nitpick [0] uses your git branches for bug tracking, and has a very easily customizable interface [1] [0] https://github.com/tst2005/nitpick https://github.com/tst2005/nitpick [1] http://travisbrown.ca/projects/nitpick/docs/nitpick.html http://travisbrown.ca/projects/nitpick/docs/nitpick.html

chriswarbo 10y ago
Thanks, I've been looking for a distributed bug tracker (for use with git) for a while. bugseverywhere seems unmaintained, and all of the other info I could find was about abandoned projects from 2011. I'll give nitpick a go :)

starseeker 10y ago

I'm quite intrigued by the libfossil project (http://fossil.wanderinghorse.net/repos/libfossil http://fossil.wanderinghorse.net/repos/libfossil) which attempts to make the core fossil VCS abilities available as a library. To the best of my understanding this is and will remain a "spin-off" project of the main fossil project, but it looks like as of August 2016 there is still active work on it. The combination of the BSD license and a self-contained C library in the style of sqlite that offers VCS capabilities app developers could build into their applications is extremely enticing. libgit2 (https://libgit2.github.com/ https://libgit2.github.com/) may have matured enough to be viable for that use case if one is comfortable with GPLv2 plus linking exception, but the sqlite-style include one header, build one C file and you're done integration is really really nice.

smegel 10y ago

Hell of a thing to write something like that in C.

bch 10y ago
Ostensibly, fossil is not written in C, but a high level language - SQL.
- deleted 10y ago
  [deleted]
- wyoung2 10y ago
  There is about 94 kSLOC of C code in Fossil at the moment, not counting SQLite itself, according to SLOCCount. SQLite more than doubles that line count. By that measure alone, about half of Fossil is "SQL", in the sense that more than half of the code merely manages the various DBs. (A Fossil workspace consists of three SQLite DBs: the actual repo DB plus two machine-specific DBs, one local to the project and one global to the user login.) There is a whole lot of embedded SQL among that C code. Simply counting the number of lines containing the 5 most common SQL statements: SELECT: 2069 INSERT: 583 DELETE: 492 UPDATE: 410 REPLACE: 122 That doesn't mean the total number of embedded SQL statements is the total of those 5 numbers, as some of that will be compound statements using two or more of the above keywords. Fossil uses some of the most complex SQL I've ever seen outside of http://thedailywtf.com/ http://thedailywtf.com/ So, while Fossil does rely very heavily on SQL, I wouldn't say it is "written in SQL." It merely delegates as much as is sensible to SQL, in the same way that a fair bit of the Fossil web user interface uses Javascript rather than call back to the Fossil binary on the server via POST and such to fetch an updated page.
deleted 10y ago
[deleted]

rwbt 10y ago

Love fossil. I use it for all my projects. Simple and easy to learn CLI (unlike some other popular DVCS) and the built-in issue tracker/wiki is very helpful. For indie devs or small teams fossil 'just works'.

SQLite 10y ago

Original author of Fossil here, with two comments: (1) Fossil was created for the single purpose of supporting SQLite development, a mission at which it has succeeded spectacularly. Fossil is therefore a success story, irregardless of its mind-share relative to Git. That thousands of other developers also find Fossil useful on their own project is just gravy. I am not concerned that Fossil has not (yet) become the "one true and great DVCS". My intent is to continue personally supporting and maintaining Fossil for at least three more decades. (2) Git people: Please steal ideas and code from Fossil. This is not about winning and losing; it is about providing the best possible tools. Fossil has a number features which are missing from Git but which could be easily added to Git and would enhance the Git-user experience. I'm not talking about the philosophical differences between Fossil and Git (which I recognize that Git is unlikely to ever change) but rather specific UI features such as "fossil all" or "fossil ui" or "fossil undo" or the ability to view the ancestors of check-ins. Fossil is 2-clause BSD, so you do not even have to acknowledge where you stole the code from. Do it for your users, please.

mysterydip 10y ago
Never heard of it before, but I'm grateful to hear about it! My projects were always small enough that a traditional version control system wasn't worth the time to set up. Just keep an archive of each day's progress in a folder and call it done. With my latest project, I'm maintaining multiple splits of the codebase for different platform-specific features, and sharing the code with a team member. I was about to bite the bullet and start installing cvs or git in a VM and going through the learning curve, but this seems right up my alley and the kind of system I'd mesh with well. Thanks!
- lucaspiller 10y ago
  > My projects were always small enough that a traditional version control system wasn't worth the time to set up There's no such thing as too small: I use Git for everything, including small scripts I may never use again. The setup is "mkdir fooscript && cd fooscript && git init". Plus using GitLuBucket means free backups.

nomadbyte 10y ago

Version control debates, why?? I think everyone agreed that having an SCM on a project is a must. Everyone most likely is using some SCM already, often-times the choice is made by someone else upstairs or in the history. Git, bzr, hg, svn, TFS (ahem) -- you've just got to use what you've got. HOWEVER, you may just as well use an SCM that is more __optimal__ for your development style, say, frequent commits, branching, stashes, private branches and then just pump the completed stages into "official" SCM -- kind of layering the version control. You can install Git or bzr etc. just for yourself? Good!, but not everyone may have such a policy. Fossil does not require installation, it's a self-contained executable, you may just as well build it from source and use it in your account. Just as simply, the same project directory may be tracked by Fossil in addition to the whatever is the "official" SCM, the only file it places in working dir is ".fslckout". I think, there's really no need to debate and pit SCMs against each other -- just use what works for you, your project, well, what fits in your own memory (it's true, Fossil command and options set is very compact, yet potent -- check it out!)

rcarmo 10y ago

I've been using Fossil on and off throughout the years, and find it to be a very nice all-in-one solution for personal projects. Collaborating, however, is an issue due to the prevalence of git (it was a bit easier in the Mercurial days because hg users were used to coexisting with something else). The biggest advantage for me is having a single file as the repo. Makes it much easier to archive stuff.

jslakro 10y ago

What about GitTorrent? https://github.com/cjb/gittorrent https://github.com/cjb/gittorrent

nomadbyte 10y ago

Perhaps another factor for minor popularity of Fossil SCM is a lack of plugins for major IDEs. I don't believe this should be such an obstacle, as most plugins implement only a part of SCM client features, thus asking you to resort to command-line for certain functions. Still, for a lot of developers the expected interaction with "everything" is through IDE. There seems to be a Git or SVN plugin for every possible IDE, yet Fossil lags in that department. JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin. We faced this with our Qt projects, and went on to develop a Fossil SCM plugin for QtCreator: https://github.com/nomadbyte/qtcreator-plugin-fossil https://github.com/nomadbyte/qtcreator-plugin-fossil Not that availability of plugins has to be such a big deal for a SCM adoption, but sure this helps a lot to increase any SCM's visibility and accessibility. In case of Fossil this probably will have to be another community effort.