You can get new post notifications through RSS, email, Twitter or Facebook
Fossil vs Git
I have used Fossil for version control for a few years, and I like it, but this recent comment on the fossil-users mailing list made me think about its limits:
we must agree Fossil [..] much easier and friendlier to use.
It is, and it is not. I do recommend it, and it does provide a a lot of functionality and it is easy to learn and use.
Why I like Fossil
Fossil wins hands down in terms of the time taken to learn the command line, and the ease of use of the command line. I like the work-flow Fossil encourages and have experienced very few problems after several years of use. I use Git because it is what all my clients choose. I do mean all: the only projects I use Fossil on are my own, and where the client leaves the choice of version control system entirely up to and I expect to work on it alone. Long term lock-in is not an issue as Fossil can export a repo to Git.
Fossil’s built-in web based GUI is also easier to use than Gitk. It does not do everything (for example, you cannot commit from the GUI) but given that this is a developer tool and the command line is easy to use this is not really a problem. It also means you can use the same GUI locally and on a server. Git is very powerful, but Fossil does what I want and more, and Git’s additional features often end up making it slower to use and creating more room for error — the need to stage changes is a good example of this.
In my view Git has two real advantages:
- Automatic detection of renames. Fossil can be awkward if, for example, you move a lot of files around, for get to rename in Fossil, and then run fossil addremove.
- The ability to completely roll back mistakes. Whether this is a good thing or not is a matter of opinion and Fossil is the way it is by design.
These advantages are outweighed by ease of use, and the convenience of having a ticket-tracker and wiki without any installation or integration work.
I am sure that Git has massive advantages for some people, particularly for large projects with huge numbers of collaborators. It was, after all, designed for the Linux kernel: approaching 18 million lines it is, as far as I know, the largest single computer program (in the sense of a single executable and excluding linked libraries), and requiring collaboration between a huge number of individuals in a huge number of organisations. For individual developers and small teams, I prefer Fossil
Git’s big advantage
Having said that Fossil is better, I now come to what changes everything: the tools and services available for Git. Installing Fossil with a wiki and an issue tracker is just a matter of installing Fossil. No configuration needed (except to set appropriate user permissions on a server). However, if you are using Git, you just register with Github (and pay if you need keep your repositories private), and you have much better issue tracking than Fossil (I suspect the wiki is better as well, but I have not used it). Fossil requires only simple server configuration, but Github requires none at all. Bitbucket provides a similar service, gives your private repositories free, and you can use Mercurial if you do not like Git. If you are working on open source software these services make it very easy for others to fork your code, work on it, and make pull requests.
If you do not like to use a repository controlled be someone else, you can use something like Gitlab, Gitblit, Trac or Redmine to provide issue tracking and wiki integrated with Git. A bit more work to set up, and you lose “social coding” advantages of Github (or similar) but you still have an excellent wiki and issue tracker, and a lot of flexibility — Trac, in particular, has a lot of plugins.
Once you have any of the above running, the ease of use advantage lies with Git. have you ever tried to teach a non-geek to use Fossil tickets? I have, and its not easy. It cannot do email notifications easily and a lot of people rely of them, and that is probably enough to make Fossil’s issue tracking unusable in many scenarios.
On the desktop you have a choice of GUIs. I use Gitg, which is nicer to use than Fossil’s web interface, although it does seem to lack the ability to diff arbitrary commits. Apart from all the standalone GUIs there are plugins for file managers and GUIs.
Fossil’s wiki and tickets are stored in the repo and are distributed do they may still be preferable for people who spend a lot of time working offline. Other than that, Fossil’s advantages, other than the easier to use command line are pretty much negated.
Fossil’s developers claim that having everything in a single executable makes it easier to install. This may be true for operating systems like Windows that have primitive software installer (although, with Windows 8, even Windows has a “store”), but on (Ubuntu) Linux I just open the installer, type “git” into the search bar, tick “git” and “gitk”, and I have everything I need. If I want the latest version I am likely to need to compile Fossil, whereas I can install the latest version of Git from an Ubuntu PPA. On ease of installation and upgrading, there is no difference if you do not care about having the very latest version, and Git is easier if you do, at least if you are on a Unix family OS (including MacOS – I notice MacPorts currently has the latest version of Git).
I still prefer Fossil (just) because of its command line, and the simple work-flow it encourages (not requires). I also like the robust repository format (it is in a SQLite database, which is a very safe and well tested option), but deciding which is easier to use for a particular project is no obvious.
Other contenders
Of course Git and Fossil are not the only DVCSs in the world, still less are they the only VCSs. However, I prefer DVCSs (multiple copies of everything, means multiple backups of everything), and they are what I have real world experience of using. I strongly prefer open source (or at least easy export to a portable format) for any data of value (I have studied to much financial theory to ignore the option value in being able to switch). I want something actively developed, with a community and tools around it. The only real options, apart from Fossil and Git, seem to be Mercurial and Bazaar. Mercurial seems to be more widely used, but both have decent tool integration. Both seem to be a reasonable compromise between Fossil and Git, with a more user friendly command line than Git, but more of an ecosystem than Fossil. Bazaar development seems to have stagnated and it is the less popular of the two, so Mercurial seems a safer choice. More active development means that even the (contested) advantages Bazaar claims over mercurial are likely to be transient.
Both Mercurial and Bazaar are written in Python (which is good, as I am not any good at C), but Mercurial was chosen to develop Python itself in, partly because it is what Python developers (meaning the smart people who develop the language itself) prefer Mercurial. I currently prefer Fossil for my own projects, but I definitely want to try Mercurial.
Comments(3)
Hi Graeme,
I’m a former fossil user (and, for a while, advocated it to all my peers/colleagues), now on Mercurial.
I used fossil for all my projects for a long time, but ran into serious problems once I needed other people to start interacting with Fossil tickets and the wiki, neither of which are any good. The ticket system especially is a show-stopper, for the reasons that you mentioned; non-technical users can’t get it, and the lack of emails is a serious deficit.
Fossil’s strength, as far as I can tell, comes from how it’s a virtually painless transition into the world of DVCS workflow for anyone who has a background with svn. You can use it more or less like svn, but with a neat little web-based gui built in, and then you get the dvcs stuff for free.
But then trying to use the wiki coming from a background with dokuwiki or mediawiki, and it’s so painful. And the ticket system is a nightmare–something you can eventually get used to, of course, but not something that works well compared to other systems.
The biggest conceptual hurdle for the fossil user to grasp, though, is the untrusted collaboration aspect of the big code-hosting services. If you’ve never used a system like bitbucket or github to host your project, you won’t even realize how neat it is that someone can fork your code, hack on it, submit a pull request, and you can review their patch through some very slick tools, leave comments or annotations on it, etc., without having to dig through “patch,” etc.
Fossil is easy to use for simple cases, but take away the crummy wiki and ticket system, and realize how much you’re missing without the untrusted collaboration piece, and it stops looking so attractive. (To say nothing of the lack of integration with common editors, like geany…)
As for Hg, I can strongly endorse using it. I use it exclusively on Bitbucket; easy commands like Fossil, but all the rest of the good stuff is *also* there.
thanks for a good post,
Steve
I do not need untrusted collaboration for most of my work – its client work, and the code is not public.
The one thing I am planning that would benefit from it is some TCL code, and I have a feeling that Fossil may be a more popular choice in the TCL world.
Thanks for the comment, and I will definitely try Mercurial
I agree entirely that the wiki and ticket system are not much good. I do not use them, but I do link Fossil’s web interface. Its pretty good, and its the same locally or on a server.
Sorry, comments are closed
Feed