Fossil SCM keeps more than just your code

In my books its a minus that you can not rewrite history. What happens if you accidentially add code where you dont own the copyright? Or an API Secret?<p>Having Tickets, the Wiki and technotes in the same place is an interesting idea, but doesnt seem terribly valuable to me. It seems to violate the unix philosophy, as in it does more than is needed. I rather have a lightweight versioning control system, another lightweight ticketing system etc., than one system which does it all.

I use Fossil for personal, private projects. I&#x27;ve never used it with other people. But being able to replicate the wiki, issues etc and version them is very cool.<p>I use fossil to keep track of my code and use the wiki of a project as a scratchpad, design document, and general notes. I love it.<p>It can be self-hosted using a super-simple CGI script:<p><pre><code> #!&#x2F;usr&#x2F;bin&#x2F;fossil repository: &#x2F;path&#x2F;to&#x2F;project&#x2F;repository.fossil </code></pre> - which allows you to both clone over HTTP&#x2F;HTTPS and access the Wiki and issue tracker via your browser. It has pretty decent access control and can allow you to configure a set of wiki pages to make read-only accessible to everyone, even when not logged in, to use as a project landing page for visitors.<p>You can also customize the CSS of a project, which is also versioned in the single sqlite db backing a repository.

I&#x27;m a long time git, hg and svn user who has been using fossil every day for over a year now and find it to be reliable, quick and easy to use. It is also very hackable and I&#x27;ve customized the &quot;fossil ui&quot; to my liking.<p>However, fossil does lacks some important features that svn, hg and git have:<p>* Fossil does not support versioning directories. In fossil only files are first class objects. It is not possible to commit an empty directory. This is a big shortcoming that all other major SCMs address.<p>* Cannot perform a &quot;fossil diff&quot; for just a directory and its descendants - i.e., no fossil equivalent of the following:<p><pre><code> # produce a diff for this directory and its descendants git diff . </code></pre> * A &quot;fossil merge&quot; between distributed repos it will give commit attribution to the wrong user for all files in the merge - changes will be recorded as being made by the user performing the merge. This is particularly annoying because it makes &quot;fossil blame&quot; on a given file less effective when pinpointing who introduced what change.<p>There are other fossil issues, but those are the biggest ones that come to mind.

I was introduced to Fossil through a previous HN post and I love it. For smaller personal projects, it&#x27;s the best. I like that I can just put the repo file into Dropbox and then have my project&#x27;s tickets, documentation, and code all in one place.<p>And from someone who doesn&#x27;t write much C, I will say that the source is very easy to read and poke around in. Just a great project all around.

This is a wonderful idea. The VCS, bug tracker, wiki, and web presence really should all be part of a packaged deal.<p>Almost nobody uses just git -- they use github or gitlab. Very few people use Mercurial, because there is nowhere good to host it. Atlassian seems hell-bent on killing hg support off bitbucket, because few people use it, a very sad self-fulfilling prophesy.<p>With offerings like gitlab, it might not make a huge difference, but contenders like Fossil or hg have some good non-git ideas worth exploring.

&gt; Git does not care about history, you can rewrite it as you feel like (git rebase). On the other hand, Fossil is immutable. Audit is possible, every action leaves a trail, and you can not rewrite it.<p>Ehm, That&#x27;s not a fair assessment. Git is as much immutable as fossil.<p>In fossils case, I can still poke around the sqlite database and delete rows from it. That may be difficult to pull of, because I expect the internal data model to be quite complicated, but certainly not impossible.<p>I don&#x27;t understand the hate against rebase. Nobody uses it with malicious intent. And, those who do, will have no problem working around fossil&#x27;s immutability.

Fossil is a great, simple system. It&#x27;s especially good with Windows because (imo) it integrates much better than the others since it&#x27;s just a single binary you can put in your $PATH. Git especially seems so hacky.

Being from Richard Hipp, the author of SQLite, it should be a pretty high quality program.

Fossil is neat and the idea of a tickets tracker and wiki within the repo is very productive.<p>However I got spoiled by the power of Git. So what I do now is to keep a TiddlyWiki[1] on the Git repo, so I have the best of both worlds.<p>[1] <a href="http:&#x2F;&#x2F;tiddlywiki.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;tiddlywiki.com&#x2F;</a>

I really like the idea behind Fossil ... but on the other hand, I want to bring all development together into one homogeneous interface: I want to do almost everything without leaving Sublime Text.<p>For that reason, I am experimenting with storing all my documentation (requirements, plans, task lists etc...) as text files in a git repository, using YAML when I need structure, and markdown when I need formatting or something richer.<p>To tie everything together, I maintain a diary, which consists of one text file per developer per sprint. This diary holds allocated jobs to do each sprint, together with a record of what was done each day.<p>Because all of my work information is available in the repository as text (markdown or YAML or JSON) - it means that I can automate my workflow in ways that would be much harder to achieve otherwise.<p>For example, I can extract appropriate git commit messages automatically from this diary, meaning that I have perfect traceability back to requirements on every commit. I can get my build to (optionally) commit changes automatically (rolling back if the build was not successful). I can even get it to (again optionally) make sure that all changes associated with a particular job are kept on a separate branch until that job is complete. In other words, I have lots of options when it comes to tying my workflow together with my CMS&#x2F;VCS in an automated and scripted way.<p>And all because I am too lazy to open my web browser to look at JIRA or Trac (or whatever).<p>:-)

By the way, does anyone know of a SCM written in Go? It seems that the feature list of Fossil would fit Go pretty well, the networking&#x2F;local web UI stuff for example, self-contained binary as well.