I’ve been a (productive) programmer for about three years now.
My workflow has been the following:
- set up a folder for the project
- start working
- create an archive of the folder with the current date each day and save that in multiple locations for backup
- rename the folder to todays date
- 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.
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
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:
hg initin the directory you want to track
hg add .to add everything
- Make some changes, run
hg commit -m 'I changed some things'
hg serveand have a web interface
I recommend using
hg c 'Changed something else'
by adding the following to your
c = commit -m
TO BE CONTINUED…