What is Reddit's opinion of Fossil?

From 3.5 billion Reddit comments

> Thing is, it doesn't.

http://www.fossil-scm.org/index.html/doc/trunk/www/concepts.wiki

"The default setting for fossil is to be in autosync mode."

http://lwn.net/Articles/433843/

"The documentation says that the author believes autosync to be the proper default ..."

I'd be more interested in hearing why he liked Fossil in the first place. I haven't really heard of it, but their site doesn't really sell me on it.

Maybe I need to see a demo, or maybe git really is king and I should just ignore it.

Too bad everyone overlooks the DVCS written by the main SQLite developer: Fossil. Actually, it is more than just a DVCS. It includes a distributed bug tracker, distributed wiki, and distributed blog. It also has a built in web server to provide GUI access through a browser.

The binary version is a single executable you place in your path, so installation is trivial. Building from source only requires C and the standard library.

So, mail clients are also bad? That is, you connect to a server, fetch your mail, reply, and push your mail. Am I out of conversation while I'm not connected to the server?

I recently worked on fixing tiny bugs (low-hanging fruits, so to say) in Fossil. Fossil is a DVCS with distributed wiki and bug-tracking. This was my workflow:

1. fossil pull to update my local repository (including the bug tracker).
2. fossil ui to run UI in a browser.
3. Find tiny bugs in the local bug tracker, fix them, commit, close bugs. If more information from the reporter needed, leave a comment.
4. In the meantime, a power outage happens in my town (really happened). No problem, I continue working, as my laptop has a few hours of battery left, and the whole project, including bugs, is on it!
5. Once I fixed a few bugs, I do fossil push and - boom! - www.fossil-scm.org (this site is the actual repository) is updated: code is there, bugs in the bugtracker are fixed or have my comments.

What's wrong with this workflow? Isn't it an improvement?

Also: bug tracker is not a support system.

EDIT: To avoid misunderstanding: I didn't have to clone/pull repository in order to work on tickets. I could have done it right there on the website, and the workflow would be no different that if I used a centralized bug tracking system. I just chose to do it locally. You couldn't do this with the centralized system.

> Maybe someone needs to work on a pretty project management system that gets stored inside the git repo itself

You might be interested in Fossil. It isn't based off of git, but it does the project management stuff all as part of the same distributed repo.

That was the original plan, and got fossil some adaptions for mega-repos. It seems they're not completely decided yet, http://wiki.netbsd.org/mailing-lists/tech-repository/, but possibly favour git again. Interestingly reposurgeon got lots of fossil-specific additions lately; so maybe it's still on the table.

Not chicken and eggs; it's more apples and oranges. It doesn't need to "take off". Fossil was developed for sqlite development. It would suit situations similar to it.

> In Git, each branch is "owned" by the person who creates it and works on it. The owner might pull changes from others, but the owner is always in control of the branch. Branches are developer-centric.

> Fossil, on the other hand, encourages a workflow where branches are associated with features or releases, not individual developers

> The Git model works best for large projects, like the Linux kernel for which Git was designed. Linus Torvalds does not need or want to see a thousand different branches, one for each contributor. Git allows intermediary "gate-keepers" to merge changes from multiple lower-level developers into a single branch and only present Linus with a handful of branches at a time. Git encourages a programming model where each developer works in his or her own branch and then merges changes up the hierarchy until they reach the master branch.

> Fossil is designed for smaller and non-hierarchical teams where all developers are operating directly on the master branch, or at most a small number of well defined branches.

http://www.fossil-scm.org/fossil/doc/tip/www/fossil-v-git.wiki

I'm using Fossil, which provides a distributed version control system, wiki, issue tracker, user management and has a command-line and web-based UI that works as a standalone server, a CGI or backend to some existing server (also i think it can work with inetd) all in a single (relatively) small executable. Everything about a project is saved in a single SQLite database.

It is basically github in your pocket (if you use a usb flash or something :-P).

I use its source control feature for, well, source control :-P. The wiki is used mostly for documentation (and as end-user pages for public stuff). Tickets for tasks, etc (you can customize them using a Tcl-like scripting language Fossil has). The custom events can be used for journal-like stuff (like a blog). Although i haven't tried it myself, some people take advantage of the scriptability to provide custom features not available out-of-the-box like discussion forums.

For some more immediate stuff and random notes i use my Outliner Lighto outliner.

That's not true. The SQLite repository itself is 1.7GB+. The stored size is 150MB because they compress everything very efficiently. This is exactly my point on scalability.

The developer of Fossil had an interesting take on this: SQL is a high level scripting language.

Well he's also the developer of Sqlite so I suppose he is comfortable with writing his logic in SQL.

edit: my take is that Rust needs a Linq more than it needs an ORM.

I recommend Fossil. It is an all-in-one package (literally, it is just a single small executable) that provides distributed source control, wiki, bug tracker, blog, web-based UI and works as a standalone web server, as an inetd service or as a CGI (which can be installed in most shared hosting services out there). It is very fast and seems to be optimized for small teams.

Everything in a repository is stored in a single SQLite database (which is itself a single file) so you can even place a "main" repository in Dropbox and have it shared everywhere (just make sure you do not have two people commiting at the same time or Dropbox will create a duplicate and one if you will need to fix it... however i believe that will be a rare case with just two people, especially if you use the shared repository file as a "remote" one and keep a local repository for your changes that is configured to not auto-commit - that last part is just a checkbox in the configuration page). If you do not like the Dropbox solution, you can use Chisel which provides free hosting for repositories and has support for "private" repositories.

Fossil works mostly from the command-line but Fuel provides a nice GUI for most file tasks and the web-based UI of Fossil itself should do for the rest. I rarely touch the command-line interface these days.

Fossil won't provide you with the best features of dedicated programs like FogBugz or MS Project, but i have found that most features go unused by small teams anyway and the Wiki is mostly enough for coordination while the portability and ease of installation and use is a very big plus. For a bit extra features you can use JavaScript and TH1 (a Tcl-like scripting language that Fossil uses), but personally i never found the need for this.

It's version control, wiki and ticket system in one, so maybe too much for your usage needs. But it's free and definitely worth more than a look: http://www.fossil-scm.org/xfer/doc/trunk/www/index.wiki

No, you issued revert, then you issued undo. There's only one level of undo, and revert is one of the things that overwrite the undo memory. That's documented here, which is just a dump of fossil help undo. I can't tell from the mailing list thread whether the repository was in a bad state or not - what is clear is fossil was reading it wrong regardless, putting your checkout in a bad state.

And again, based on that thread, you didn't lose any committed code. Once it's in the SCM it's there. Fossil is very good about that. Fossil couldn't find it because it got lost on the commit tree, but it was there. I still say it's disingenuous to entirely blame an SCM for loss of code you hadn't committed.

For context, more information about my needs: I am not a company, I use the website to host my blog, a fossil version control system and free applications that I write and distribute. I also store personal files to share and many sub-domains with stuff like community wikis and ticketing system. Shared hosting is enough IMO.