Mercurial does not track directories explicitly though. So the way a directory rename works is that if all of the tracked files in a directory move to a new directory, then when you update or merge that revision, all of the files including untracked files will be moved. I would agree that it’s not perfect, but I don’t think it’ll produce any particularly bad results very often. At worst you just have to move a few files manually after the merge. Since these files have no merge conflicts (if they did, the merge machinery would discover it and handle it for you), it’s a pretty trivial operation in my opinion.

As for IDE integration, I think that’s still young. I do know that an eclipse plugin has been started, as well as a tortoise-like GUI for windows.

I read that hg wants bzr’s merging edits across renames support.

That was a year ago. Maybe Mercurial implemented it. That was what I was getting at. I figured they would have done it by now. If the information is all there, after a rename, the “hg log” command ought to show the rename rather than the copy+remove. Otherwise it leaves you wondering.

In addition tonfa’s comments about Mercurial’s heuristic handling of directory renames is not encouraging. I don’t want my SCM to use heuristics… even if Linus says that’s adequate – even better!.

I’d be interested to get to the bottom of this. Part of the team is offshore at my current client and I have been recommending upgrading to Subversion from ClearCase LT 2003. However, since noticing a few other issues – particularly for the offshore team, I am wondering whether to push for Mercurial is the better way to go – hence I am putting it on trial at the home office. This is a Java shop so IDE support is a big plus.