Background

I’ve been a (productive) programmer for about three years now.
My workflow has been the following:

  1. set up a folder for the project
  2. start working
  3. create an archive of the folder with the current date each day and save that in multiple locations for backup
  4. rename the folder to todays date
  5. Back to step 2

I was aware pretty much from day one that this wasn’t the best setup, but it worked and I didn’t have to worry about any tool clobbering my work and leaving me with lost files

I remember that happening at the time, as Zed Shaw went from a massive fan of fossil, to, well, not a massive fan.

Over the years, I’ve tried Fossil, Git and Mercurial (and probably others).

I always came to the conclusion that I’d need to put in too much time to learn their intricacies to bother with them.

Anyway, last month I decided to revisit SCM again. As I’d been using SQLite a lot, I thought Fossil would be ideal as it’s used as the SCM for SQLite itself.

My Thoughts about Fossil

Fossil uses an sqlite database as the repository. One of it’s best features is that it’s an SCM, a wiki, a bug tracker, a forum, a website, and probably other stuff too.

What annoyed me very quickly though is the workflow:

  • Create a directory ~/fossil where you store your repositories
  • From that directory run fossil new project.fossil /path/to/where/actual/code/is
  • Then run fossil open /path/to/where/actual/code/is
  • Get a warning from fossil that the directory is not empty and must use --force to override

I mean, come on! So, I ditched the idea of using fossil and thought I’d see what Mercurial (hg) was like nowadays.

Here is the hg way:

  • Run hg init in the directory you want to track
  • Run hg add . to add everything
  • Make some changes, run hg commit -m 'I changed some things'
  • Run hg serve and have a web interface

I recommend using hg c 'Changed something else'

by adding the following to your ~/.hgrc

[alias]
c = commit -m

TO BE CONTINUED…