wyoung2

While I am a fan of chains of small cooperating tools, there is something to be said for a single large tool with a well-integrated feature set.

Here are some of the advantages you get when the code repo, bug tracker, and wiki are all part of the same coherent system:

1. When a checkin fixes a bug noted in the ticket tracker, you can reference it in the checkin comment with a subset of the ticket ID: "Fixes [3b52b91fc]" That ticket ID becomes clickable in the web view of the timeline, taking you directly to the referenced ticket. Yes, I know, this is not a unique feature, but the other systems that have this also integrate the ticket tracker and code repo. The point is that you get this feature out of the box with Fossil, for free.

2. Your next step is to close the bug ticket. This modifies the appearance of the checkin comment you created in the previous step in the Fossil UI timeline view, rendering the ticket ID as strikethrough text, so you can see it refers to a closed ticket without clicking on it. The key point here is that the integration is bidirectional.

(It would be even neater if Fossil would recognize the pattern "Fixes [artifact-ID]" in checkin comments and automatically close the ticket for you. It shouldn't be too difficult to add, since it's a unified system.)

3. Anywhere that Fossil accepts regular URLs, it will also accept artifact IDs. So, you can refer to checkins or tickets from the wiki, or from within a Markdown document checked into the code repo.

4. Because Fossil understands Markdown as one of its available wiki article formats, it can render Markdown documents in the code repo inside the Fossil UI when you click on them from the Files tab in the web UI.

5. That feature extends to other document types, too. This leads to the embedded documentation feature (http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki) which is a versioned alternative to the wiki. You use the wiki for articles that apply to all versions of the repository, or at least to the current trunk version. Where you instead need a given doc article to roll back to its historical content when you roll back the code, you want to use embedded documentation instead. You can use the wiki and embedded docs interchangeably, linking from one to the other, as needed.

> Fossil does not support versioning directories.

While that is true, what would revision 2 look like? "This new directory is also empty, but more so?" My point is that an empty directory isn't really "versionable," in the sense that there is something there to be diffed.

I converted a few Subversion repos to Fossil, and the empty directories I'd stored were all easily replaced by a dependency in the build system, so that it was created at the point of need. In that sense, the directory is versioned as part of the Makefile.

In many cases, your existing tooling already takes care of this, as with "bin\Debug" and such in Visual Studio.

> Cannot perform a "fossil diff" for just a directory and its descendants

Yes, that would occasionally be nice.

Fossil does support directory names in checkins, though, so if you're certain the changes are all confined to one subtree, you can just check that change in, then diff what's left.

You can also "stash" a directory, then either diff the stash against the working checkout, or diff what's left, as your workflow requires.

> A "fossil merge" between distributed repos it will give commit attribution to the wrong user

I suspect that's because the full user table isn't included as part of a clone, nor are local user changes pushed back to the repo you cloned from.

The idea of federating identity management gives me the heebie-jeebies. Just ask the PGP folk how well that works.

If repo A clones from B, which clones from C, and you want changes made to A to be properly credited in C, the owners of A need to acquire a login on C, sync themselves to C instead of your B repo, and then check their changes in directly, bypassing B.

Rebasing can move whole subtrees around in the repo's history, then publish all those changes back to the repo you cloned from. There is nothing like this in Fossil, on purpose.

Fossil's shun operation and private branches are entirely different from rebasing.

First, shunning: that just nukes a particular artifact from the local repo, leaving a hole in the history. You can't push a shun operation to another repo, and if you do the shun on a central repo, any clones of it that were made before the shun don't copy the shun record, so they keep their local copies of the shunned artifact. The only way to propagate a shunning operation through a clone network is cooperatively: you have to ask everyone to agree to shun that artifact in their local clones, then rebuild their repositories.

As for private branches being a "history rewriting" mechanism, that's nonsense. Changes made to a private branch are never part of the history on the repo you cloned from in the first place. They're analogous to the default working mode of Git, where your checkins aren't immediately sync'd to the repo you cloned from. If you never sync, or you purge your local changes, history doesn't get rewritten, the changes just never become part of the official history in the first place.

> What is the value in having history be static?

Because you can trust it. Rewritable history is like maintaining your business ledger on a whiteboard.

> I find that rebase comes in handy as I'm working locally

This idea that local development is a good thing is one of the biggest differences between Git and Fossil.

Git was created to serve the needs of the Linux kernel, where the development effort is not only distributed, but also federated, with islands of development sporadically pushing changes higher up the tree. You see this on Github, with semi-private forks of projects containing changes that never make their way back into the primary project. If that is the sort of project you're working on, Git is the right tool.

Fossil, however, is meant for much more cohesive teams. While it does allow one to go off on a tangent, developing for weeks at a time with no outsiders ever seeing what you're doing, that is not its default mode.

In Fossil's default mode, local checkins are immediately sync'd back to the repo you cloned from, which is typically the official central repo. Fossil allows you to have chains of repos (A clones from B, which cloned from C, which cloned from D...) but a simple 2-level fan-out is much more common.

I think of Fossil as a DVCS with the day-to-day workflow sensibility of Subversion.

The DVCS aspect means you can take your laptop to the mountains with you, code for a week in your tent while your relatives all enjoy the dubious pleasures of nature (the weirdos) then come back home and sync back up with the central repo, your whole change history being grafted back in as if you'd been autosyncing to it the whole time.

The Subversion sensibility means that while working in the office, every checkin normally becomes immediately visible to your team members, as do theirs to you. While this makes some people nervous — particularly those who have only used Git — it has benefits.

I can state those benefits in terms of the [Ten Commandments of Egoless Programming](http://goo.gl/13r3xT), published by Gerald Weinberg way back in 1971 as [The Psychology of Computer Programming](http://goo.gl/NqqGnl). Using his numbering:

1. You will make mistakes, but Git encourages you to hide them in the stash, in private branches, in changed checkin comments (git commit --amend), and in history rewrites. In its default working mode, Fossil pushes every checkin immediately back to the repo you cloned from, where they can be noticed and fixed ASAP. The longer an error goes unnoticed, the greater the damage it can do.

2. You are not your code. Private branches are a symptom of the sort of perfectionism that violates this commandment. You don't want to spend a week going off on a tangent when one of your colleagues could have saved you from wasting your time by seeing the path you started down with your first commit. Fossil has a way to create private branches, but unlike Git, it isn't the default mode. Defaults matter.

4. Don't rewrite other people's code without consultation. You've worked with that guy. You know, the one who runs the whole codebase through indent(1), the one who changes multi_word_function_names to camelCase, the one who "refactors" things endlessly. Git's default mode of working on a private branch, then pushing a bunch of work as a single bolus makes this sort of fiddling worse. Fossil's default autosync mode lets you detect that sort of thing early and nip it in the bud.

6. The only constant in the world is change. So, when a colleague makes a change in trunk that breaks your change-in-development, you want to pull it into your tree ASAP so you can fix up the problem before trying to merge your change in. You don't want to find out a week later when you and your colleague both try to check in week-old private branches, and find that you'll need another day or two of work to fix up the differences.

9. Don't be "the guy in the room." But Git wants you to be that guy. Before you can check a change in with Fossil, it first checks if there are any changes in the repo you cloned from, and makes you either say "fossil up" to pull them into your local repo, or check in on a branch. This encourages you to either test your changes against the tip of trunk before checkin in, or at least publish your changes as a branch so people can see you go haring off in a different direction, and maybe correct your trajectory.

Not all merge conflicts can be detected by the VCS's merge algorithm. Just because your changes merge cleanly into the central code repo doesn't mean you haven't broken the build, or the tests, or... Fossil encourages you to test your change against the tip of the branch you're working on before checking in.

Git amounts to a social regression with respect to Egoless Programming.