The setup

My first ever talk done outside of the work place was about using the right tool for the job. And that has remained a concern for me. I do like certain tools, languages, approaches … but if they are not appropriate for what I am doing currently, or a better option is available, I think I need to use that different option. Recently, I’ve been thinking about Git, and the fact that seems to be used everywhere.

Git

Let’s going to start with the disclaimer: I do like git. It goes up front so people don’t get the wrong impression. But having said, that doesn’t mean is a perfect tool. The most contextual element to understand is that it was created to cater specifically for the needs of the Linux kernel development, which uses the Linux Kernel Mailing List as the driver for all the work that they do. Is a non-corporate environment (even if multiple corporations have people working on it), with (as someone put it) a drive-by-patch culture. Some of the solutions are ingenious (I do love the idea of git patches). Some of the decisions don’t work as well outside of their specific process.

Github added the idea of PRs to the flow with git (because for most people, using a mailing list and git patches was not something they wanted to do). Which works for a low trust distributed system, but it is actually detrimental to a well integrated team (alternatives like pair programming and ensemble programming I consider superior to PR). I have seen this making the rounds in twitter lately, and I agree with them (Jessica Joy Kerr, for example)

The company view

I have talked about context before. I am fully concerned about what is the best environment for a permanent team either co-located or in constant communication to operate in the most efficient manner for the development of the system. That is the context under which this small post is created. The context in which git was developed doesn’t apply to most companies. You don’t allow anyone to contribute from outside (we have now companies doing Open Source, but that is something we maybe talk about another time). All the code created belongs to the company. There are security implications for the code. You will need certain tooling for project management. Sometimes you are affected by SOX or other regulations. And probably we could find a few more differences.

Fossil

In the past I have used other source control tools: Visual SourceSafe, TFVCS, CVS, Subversion, Mercurial(really briefly). Each one with their strengths and weaknesses (some mostly weaknesses). I have just started to evaluate Fossil.

I have heard about Fossil some time back because of SQLite. Fossil was created to cater for their way of working on the development of SQLite. Like Git, they have an specific itch that they fixed for their specific context. That doesn’t make it better or not in general. Just different.

Quick introduction for git users

In their documentation they have a few nice explanations about different parts of how Fossil works, like this Git to Fossil Translation Guide. Give it a read if you want to know a bit more about it. I found it illuminating.

The single repo file

So Fossil has a single repo file, which is basically a SQLite database. This resides outside the folder where the code is (unlike Git or Mercurial that have a .git and .hg directories inside). I need to play with it more to see how good or not this is. But I understand the basic idea of why is like that.

Autosync

Let me get excited about this idea: whenever you commit, it pulls before the commit happens, so you can fix any merge issue, and then pushes your changes to the remote. This is awesome. There are no big merge issues because they are all small, continuously getting up to date. This behaviour is kind of similar to centralized systems, but you have better handling of merge issues and going offline. No more massive merges.

Lack of rebase

I tend to use rebase a lot. But just because I can, doesn’t mean I should.

Let’s start with this awfully titled bog post from Fossil themselves in which they talk about why they do consider rebase bad: Rebase considered harmful. I am in concord with them.

Something you should avoid, as much as possible, while working for a company, is rewritting history. I am surprised that so far no one has raised the issue that it could go against the legal obligations of a company (at least not that I have heard of).

Public branches vs Private branches

When you create a branch on Fossil, by default, the branch is public and therefore part of the autosync. From the point of view of a company this a desirable outcome. In general, I see no reason why a branch should be private (notwithstanding the fact that I prefer trunk based development, only way to get to true Continuous Deployment). One scenario you avoid with this is: "person X was working on branch Y, but they are off sick now, and they didn't push their branch, so we either wait for them to come back or we start afresh". And who says sick, also means holidays to the middle of a valley in no-where, or left the company.

Partial commits

This is when you select only some of the changes that you have done to be committed. Another option that I have abused in the past, but shouldn’t really do it. The fact that you are pushing changes that are not properly tested is actually horrendous. Maybe you forgot to push one line (or more). Maybe the interaction that you though happened only happened because of lines you are not pushing up. This is bad behaviour.

The Future

In the past, I wanted to leave behind centralized systems like TFVCS because there were difficult to work with, getting constantly in the way of what I was doing. Git was raising in popularity and I went that route for a distributed source control system. But the more I have used it within companies, the less convinced I’ve become of it. Mercurial has the better UX and less internal leakage, while Fossil seems to work better for a company (at first view) as it has better alignment. Is possible that in the near future I would recommend for companies to start new projects in Mercurial or Fossil, because I do believe that, from a company perspective, they are the better options. Of course, if you want to allow external collaboration, Fossil doesn’t seem as good, while both Mercurial and Git seem the better options.