Rebase is very nice in the simple case (no or few merge conflicts), but if you have a lot of them it can be more trouble that it's worth, compared to the regular merge+commit:
Rebase changes your commits & alters history, and by default removes your original commits. This has a number of implications which are quite hairy if they hit you in a bad moment:
- No way to see how you resolved conflicts. (i.e. diff between your original commit and the rebase, unless you elect to keep them and manually strip them before pushing)
- No way to test each rebased revision merged ok, compiles and runs ok before committing them. You rebase, your commits change. (same exception as above)
- If you are really doing distributed stuff and sharing/pulling from many sources, you must be extremely careful not to share any commits that you intend to rebase.
- Additionally, if, in the above scenario, you accidentaly rebase then pull these pre-rebase-commits from someone, you get a double set of commits and need to 'hg strip' out one set of them. (I haven't tried to merge here.)
The problem is that rebase edits history. Which is what SVN does on 'update'. So, it's definitely something you could use, but if you have many outstanding commits and expect many conflicts, I recommend a merge instead.
