Don’t push them, then. Even when I use named branches, I only push/pull my current branch/bookmark. I have right now a dozen or so branches that have never made it up to the central repo, that no one’s ever seen. Pretty much like how I’d work with git branching really.

I’ve tried do this operation with “-r” and it seems to work correctly…
PS: hg –version: 1.6.1023

I’ve done the folder thing for about a year with SVN, I just prefer having a single repository. There are advantages to having one repository over multiple folders, and conceptually I find it easier to manage. Otherwise, the actions are pretty much the same.

I tend to stay away from TortoiseHg, I work faster from the command line. My mouse is lonely

@Arnis

- Better integration with Windows
- Extensibility model
- Configuration

@Ike

Funny, a teammate just brought that up to me the other day, thanks for the tip!

# hg checkout SomeTopic1
# hg bookmark -f master
# hg bookmark -d SomeTopic1

could be shorter if you don’t really need the checkout (because you’re going to work on SomeTopic2 next) you can also specify “-r” together with “-f”

hg bookmark -f master -r SomeTopic1
hg bookmark -d SomeTopic1

You mentioned moving back and forth between features and branches very fast. Well this is complicated, why do you like to complicate your life? plus from visual studio there is no way to tell which feature you’re working on when you come from the coffee break. With local folders you can. finally, KISS:)

Git’s workflow is simpler because this is all built in. Local branches are “the way” to work, and are not an afterthought as it is in Hg.

Maybe I have your workflow wrong. To start new work, the first thing I do is create a new bookmark. This would mean in Hg land, clone into a new folder. Bookmark = 1 very cheap step; new folder+clone = two steps, cheap because it’s local, but not close to as cheap as bookmark.

Doing normal work is the same. OK, now additional work comes in, and I have to abandon that folder for now. Do the same, create new folder, clone from the “master/trunk” folder. With topic branches, it’s checkout master, bookmark. Because it’s a checkout, it’s cheaper than a clone.

Now I want to fold changes from the additional work back in. So you pull and merge/rebase not from local trunk, but from server trunk, make sure everything works, and push it back out. Here local branches in Hg is more complicated, as the extensions don’t support a fast-forward merge as Git does. Bookmarks adds 1-2 steps here.

This is the exact workflow I used with SVN. We had feature branches, and created a folder per feature, and had one folder for trunk. Switching between branches meant loading up a new solution from a different folder. With Git and Hg, I can now accomplish the exact same workflow, but now all in one local repository (very, very fast) and one local folder.

Still, the main disadvantage I see with multiple repositories is the conceptual overhead of multiple repositories. With bookmarks, I’m working with commits. With folders, I’m working with file operations. When a bookmark is completed, I just need to delete the bookmark. To delete a folder, it’s more expensive and I have to make sure that everything is closed. With hg checkout, I can move between trunk/topic branches with ease, and not have the extra burden of managing folders.

There are definitely benefits and drawbacks to both approaches (and others). Going from SVN -> Git -> Hg, I saw the benefits of local topic branches in a single repository in the SVN -> Git change. Although it’s more steps in Hg vs Git, I really like the benefits that a single local repository gives me, from very very cheap local branches to fast switching to a single, unified view of all my local work.

It depends how you measure complexity, but for me copying folders and giving them names is way simpler than the workflow described above, in orders of magnitude.

It is strange to know that folder-based branches are unheard with git. I have never used git because of its complexity compared to hg, so i can’t speak to that.

Maybe you should work the hg way instead of forcing a git workflow that is foreign to it.

Right now I have 4 topic branches locally that have not been integrated back to trunk. Why would I want the additional complexity and maintenance overhead of putting these in separate folders?

With git, doing folder-based topic branches is pretty much unheard of. This is because local branches are a first-class citizen, making the need for separate folders moot. I do have to work in a couple of extra steps in Hg for local topic branches versus Git, but I can now manage exactly one repository, versus one repository and folder per branch.