Stop tracking a file in Mercurial

Since I read The definitive guide to mercurial, I've been using mercurial daily at $work , and following a branch-per-feature workflow with more or less success (I'm very satisfied myself, but I keep forgetting the commands).

Today I took a project I was coding some time ago, and when I did my first commit... I saw mercurial was tracking a binary file I didn't particularly wanted to track (some temporal .o in CMakeFiles dir).

Here's what I did to untrack ChironEA.o file:

rgrau@ares [ ~/chiron ] %hg commit -m "FooBarBazQuux added"
rgrau@ares [ ~/chiron ] %hg vi
rgrau@ares [ ~/chiron ] %hg rollback
rolling back last transaction
rgrau@ares [ ~/chiron ] %hg remove src/CMakeFiles/ChironEA.dir/ChironEA.o                  
not removing src/CMakeFiles/ChironEA.dir/ChironEA.o: file is modified (use -f to force removal)
rgrau@ares [ ~/chiron ] %hg remove -f src/CMakeFiles/ChironEA.dir/ChironEA.o
removing src/CMakeFiles/ChironEA.dir/ChironEA.o
rgrau@ares [ ~/chiron ] %hg commit -m "FooBarBazQuux added"

Little by little, it seems I'm starting to do things the right way (tm).


Btw, I've packaged latest mercurial version for vectorlinux (yeah, that little fast distro I happen to use and recommend)

upgrading mercurial and closing branches

If you follow my blog (unlikely), you already know I've been reading about source version control alternatives.

At $work, we use mercurial, but we had a quite old mercurial version (0.9.5). At that time, mercurial wasn't able to close named branches, so when you opened a new branch, you had to carry that branch with you forever. It was not really suited for a-branch-per-feature workflow.

Since mercurial 1.2 though, we can close branches with a --close-branch flag when commiting.

First things first. Upgrading mercurial is not that easy (at least in Ubuntu 8.04)

There's a launchpad user that seems to upload mercurial builds, but I never figured out how to use launchpad. My damn ubuntu can't manage the gpg key or whatever.

Installing from source requires python-dev and python-setuptools. apt-get install them .

Then, you can easy_install Mercurial, and hopefully it'll work.......OOOOOPS, no :)

you see some warnings there, right?

***** failed to import extension hgext.hbisect: No module named hbisect**

ok, as root, go to /etc/mercurial/hgrc.d/hgext.rc and comment the line with

bisect=

After that, you'll have a working updated mercurial, but probably, your hg view command will disappear.

you can find hgk in the source mercurial package, in the contrib directory.

wget http://www.selenic.com/mercurial/release/mercurial-1.3.1.tar.gz

Just untargz, and move mercurial-1.3.1/contrib/hgk to anywhere in your path.

Now with mercurial 1.3.1, my workflow can follow a-branch-per-feature without problems.

hg branch checkSinglePond
echo "say 'hey! I'm a new feature' ; " >> foo.pl
hg commit -m "fin de feature"
hg up default
hg merge myNewFeature
hg up myNewFeature
hg commit --close-branch -m "closed"

That's what I did the first time, but well, I thought if I could close a branch when commiting real stuff. It only makes sense if later, we plan on merging.

hg branch BarFeature
echo "say 'bar' "; >> foo.pl
hg commit --close-branch -m "added and closed"
hg branches # only shows 'default'
hg up default
hg merge BarFeature
hg commit -m "I'm Tip, with BarFeature Merged after closing"

Here's a screenshot of the mess :)

I'll keep posting my findings about version control and how I keep modifying my workflow to fit its 'best practices' ¬¬ .

mercurial vs git which one to choose?

Lately I've been more and more concerned about the importance of version control systems due to my late work on multiple features at the same time on one of my Evolutionary Algorithm app at $work.

I've been reading some texts about distributed vs centralized version control and the advantages of DVCS seem clear, but not being used to work with other people, nor maintaining various developement branches, I find a bit daunting managing my codes without some reading about DVCS.

Let's do some reading then!

I've briefly skimmed some blogposts and homemade comparisons, and finally I tried to find complete free books.

That's the order I think it's the best to understand pros and cons of one and the other system.
In this first article ( http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ ) they explain the main differences between the two.

Fairly the well-known stuff:
git is more flexible,
git is more cumbersome at first.
git is faster than mercurial.
git installs about 150 binaries in your /usr/local/bin
git makes branching cheap

hg is very robust
hg is well documented (better than git)
hg is ready to use
hg is more compact than git

It seems that hg uses the motto "convention over configuration", and git is just the other way.

Here there are a couple of webs that compare one to other in a more procedural way. How git people tend to work and how hg do it.

http://lists.freedesktop.org/archives/cairo/2006-February/006255.html
http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/

And here there are some comparison between workflows in both, git and mercurial. Theese are the key to understand branchy development.

http://www.rockstarprogrammer.org/post/2008/apr/06/differences-between-mercurial-and-git/
http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less


different workflows explained:

http://bazaar-vcs.org/Workflows

Git evangelists && book
http://whygitisbetterthanx.com/ is clearly progit, so it may not be updated respect hg
http://gitready.com/
http://progit.org/book/

Mercurial evangelists && book
http://jrawio.tidalwave.it/development/mercurial+best+practices/
http://video.google.com/videoplay?docid=-7724296011317502612#
http://hgbook.red-bean.com/read/

Yesterday I just finished the 'mercurial definitive guide' book, and theese days I'll take a look at 'pro git', but I think that today, mercurial has the same facilities as git when it comes to branching, and despite not having the staging area, and some other little idiosyncrasies, one can use mercurial with the same workflow as git (one branch for qw/feature bug release experiment/ ). Being able to close branches allows us to use branching instead of cloning , and then end with a update, merge, commit and --close-branch . There's a lot of outdated info about mercurial branching system... you know, teh intertubez is full of moving targets.

All in all, I think I'll keep using hg at $work, and try git here and there on my little github projects.

Next book to finish reading: Effective Perl Programming.
Book I allow myself to start again (and probably won't end): SICP