Mercurial workflow for private branches with multiple machines, serving a single central repo

Question

I have an svn repo, and I'd like to use Mercurial as a front-end to it. I've been testing hgsubversion and it seems pretty good.

I commonly have to switch between machines while writing and testing code, and I'd like to be able to check my stuff in (on a branch, mq, not sure yet) in such a way that I can get it on the other machines, edit there and push back and so on, and only when I'm ready push it to the central repo.

In git, I'd do this with temporary private branches that I'd push and pull between my machines. Then I'd rebase back onto the main branch and push to the central repo. But I'm still getting used to hg's quite different branching model and I don't see which of the many choices makes the most sense (clone, named branch [they're permanent?], anonymous branch, mq...)

Any hints for a mercurial newbie?

Answer 1

Just use separate repos for "central" and "in progress". Have your central, meaningful repo be the place where you push changes you're ready to share with the world, and until you're ready to release them push them to a separate '-devel' repo. Push and pull to that from all your machines and promote -devel into formal with a 'push' when you're ready.

You can get fancier and use a patch queue (mq) in devel that is itself version controlled, if you don't want the resulting changesets to necessarily match your in-progress changesets, but I'm a fan of exposing the process as much as the result, so I don't go that route.

Either way though push and pull are all you need to keep in-progress work going to/from a -devel repo (or versioned queue) and then migrate up to central when you're ready.

(The LocalBranch extension suggested in a comment on the question itself isn't at all what you want as they don't migrate between machines at all -- hence their name.)

Answer 2

What I usually do is use bookmarks or locally-created nambed branches in Mercurial. The local named branch will lose its name when it gets pushed to Subversion, and the bookmark is transient anyway. That lets you avoid having tons of repositories laying around and keeps things clean(er).

Pushing and pulling "behind svn's back" can lead to a slightly confusing set of revisions from time to time, since hashes necessarily change when you push to Subversion.