Doesn't TortoiseHg Auto Synch with Server

I have created a repository on https://bitbucket.org/ and use TortoiseHg to clone it to a folder in my local machine. I am able to add files commit files, but what I find is they never get updated on the Server at Bitbucket. By some fiddling, I found that there is this synch option. What I don't get is, why do I have to press the Synch. If I meant to commit, th开发者_C百科en it should commit.

Where is it being stored If it's not synched immediately with the remove server.

Note: I am trying out TortoiseHg and Mercurial while having ample experience on SubVersion.

When you commit, you commit to your local repository - i.e. to the .hg directory in the root of your project.. To synch with the remote repository you need to explicitly push your changes. This is how DVCSs work - it's not the same model as SVN.

A key feature of a distributed version control system is that you can make local commits. This means that the new commit does not leave your machine when you press "Commit", it is just stored locally.

This has some direct consequences:

• you can work while you are offline, e.g., in a train or in a plane

• commits are very fast: in Mercurial, creating a new commit involving n files (normally called a changeset) means appending a few bytes to n + 2 files.

• you can change your mind: since you have not shared the new changeset with anybody, you can delete it from your local machine without problem

It also has some indirect consequences:

• because commits are fast, people tend to make many more commits. The commits are typically more fine-grained than what you see in a centralized system and this makes it easier to review the changes

• because commits are local, it often happens that people do concurrent work. This happens when both you and I make one or more commits based on the same initial version:

                  [a] --- [b] --- [c] <-- you
                 /
  ... [x] --- [y]
                 \
                  [r] --- [s]         <-- me
  

  The history has then effectively forked since we both started work based on changeset y. For this to work, we must be able to merge the two forks. Because this happens all the time, you'll find that Mercurial has very robust support for merging.

So, by decoupling the creation of a commit with the publishing of a commit, you gain some significant advantages.