Christophe HENRY

Ce site ne comporte aucune information d’intérêt, sauf pour celui qui la cherche — Ĉi-retejo ne enhavas informon interesan, krom por iu kiu ĝin serĉas — This website doesn’t have any information of interest, except for who looks for it

Fossil, a versionning system all-in-one: short review

icon 24/02/2013

Git branching model Besides big players like Mercurial and git exists Fossil. It is a Decentralized Version Control System as the two others. It's main difference is that not only does it embed the versionning system, but also provides a wiki and a bugtracker. So when you clone such a repository you also get the wiki and the bugtracker. This has obvious advantages: you don't need to connect to any server to update documentation or to fill in a bug. Do your job as you would do for your source code, and voilà!

Wiki

I gave it a try. I don't like the wiki itself. It's not that the syntax or whatsoever is not relevant, but there's a cumbersome problem synchronizing a wiki with the source code. Say there is a development branch and a stable branch. You update the wiki of the development branch, write things about what you develop. Then it's fine. Say you rewrite something about what already exists in the stable branch. How do you propagate these changes from development to stable branch? You could try a copy/paste, if there's not many modifications. But, normally, you think of a merge. And it works. But, how can you explain a merge at this stage: the production branch merges a development branch. Developers may think that a hotfix was just picked up!

The problem is solved on Mercurial/Git by maintaining a wiki in a separate repository.

Indeed, that 's a common problem. The same problem occurs when you deal with external libraries. In Subversion, you create vendor branches, in Mercurial, you create sub-repositories or the like. The wiki is almost useless as its lifetime is not correlated to that of the program. Indeed, Fossil itself don't use its wiki! They say We find that embedded documentation works better than wiki for documenting Fossil itself since embedded documentation is versioned along with the source code, and so given a particular version of source code, it is a simple matter to find the corresponding documentation.

Bug tracking

I'd rather dream of a sort of replicated database to which I can plug my own front end. In most of projects, we may either deal with bugs by email, dedicated software or something else. There's many ways to do this, each of them with advantages and inconveniences. So, why would we be happy with the only way of handling bugs?

This problem is not totally solved by the two others repository providers BitBucket and GitHub, as they provide both such a tool but without a way to synchronize it out of their website. Contrary to the wiki, it's not easy to store the contents of the bug tracker in a repository. If one existed, it would be awesome.

Rebase

The last important thing I'm concerned about, is the rebase. About rebase and all history-modifying tools, Fossil says (3.8 Audit Trail) Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. The lack of a "rebase" function is considered a feature of Fossil, not a bug. (I highlighted some words)

It's just stupid. Everyone would like to be perfect. But we know, that, hidden in the heart of our local repositories, we all are pigs. We all need, at a time, to rewrite the history. Especially to rebase.

Rebasing Here is an example. On the picture besides, you can see a typical use case:
* Someone made C0, C1, C2.
* Alice creates locally her commit C3.
* Bob push his commit C4.

If Alice pushes, she would create a new branch as her commit is linked to C2. What she can do is to pull the changes to her side, getting C4 and to rebase. Her commit C3 will be linked to C4. All the commits are now in a single line. Fossil wants the history to be fully visible. In this case, she would need to merge, leaving her dirty and unwanted branch at the sight of everyone.

Under Subversion, which is a centralized system, the problem is similar. Because people don't want to make dirty commits, they do late and risky commits. Please remind that in Subversion, any commit is equivalent to a push in the distributed systems. The very good point in distributed systems is that their permit such history manipulation before sending any commit. Personally, I sometimes used Mercurial in conjunction with Subversion to locally make some mercurial-commits, branching before making the subversion commit.

Is it used

Yes. Making a google query against a typical sentence visible in the web interface, I found some links:

So what?

I don't recommend the use of Fossil. The idea behind an embedded wiki and bugtracker is valuable, but not the lack of history management.

icon Tags de l'article :

Aucun commentaire

icon Flux RSS des commentaires de cet article