Any Change Creates New Heads?

[Doug Philips]

Some additional text that might be of help to CVS users moving to Hg:

...
Ok, so if commit != push(share), now what?

It can be hard to break the CVS thinking habits about commit:

    * Q: I committed my changes, why can't anyone else see them?
      A: because commit != share, you need to push to make Changesets visible to someone else.

    * Q: I try to push, but Hg says that there is nothing to be pushed, what happened?
      A: You have to commit your changes before you can share them.

    * Q: Arghh! I have to commit and push? That seems like twice the steps and work! Is that better?
      A: To the CVS way of thinking it would be twice the steps. To the Mercurial way of thinking, it breaks apart the CVS operation (commit changes == share changes) into separate steps. This frees you to commit changes whenever it makes sense, and it frees you from having to share changes when you just want to commit.

      This takes some getting used to for most CVS users. Good Hg use frowns on massive commits of unrelated changes as a sign of lingering CVS thinking: I can't commit these changes, I'm not ready to share them. Oh no, now I need to make more changes, and now I need to fix this other thing... (time passes... a week or three later...) Whew, now everything is working again, time to commit! Yes, CVS users can work around the commit==share "feature" by using branches. But you have to be careful doing so because CVS makes branch merging painful. By splitting apart the CVS commit into its fundamental concepts of recording (committing) changes and sharing (pushing) changes, Mercurial gets out of your way instead of requiring work-around processes.

Note: Pushing to a central repo is still very much a concession to the CVS model. Mercurial is really geared towards using a pull model, but for transitioning CVS users, the Mercurial's push model is a reasonable intermediate step.

--- end of snip2 ---