Using Git or Hg, if the whole team is using pull and push from a central server, how is it different from SVN?

Say, if the whole team using Git or Mercurial is doing:

(example in Mercurial (Hg)):

hg pull
hg update

  [edit开发者_StackOverflow files or add files, and test]

hg add .
hg commit -m "good"
hg push

I don't see how it is different from using SVN? If the team never push or pull to another member, but just pull and push to a central server. (unless if we say merging is better, but merging is the job of SVN or Git/Hg, just depends how well a job they do it, but not dependent on whether it is a DVCS (Distributed Version Control System)). Is that true?

One difference is that you don't have to push every time you commit. For instance I often commit several groups of changes during a day of coding, and then push once at the end of the day.

With Subversion each person only has a single revision of repository on their local machine at a given time, they cannot view revision history or rollback to a previous revision without connecting to the central repository. With Git and Mercurial, each person has a complete copy of the repository, and thus can do all of the above locally without needing to connect to the central repository.

Git and Mercurial need only connect to the repository to push up locally made commits and fetch commits not yet in the local repository. Subversion cannot function at all without a connection to the central repository.

I think your statement is generally true and at the same time can have a lot of different answers.

The DVCS gives you possibilities that are not possible with a central repository model like svn :

• When the server goes down, users still have the whole history and can work as if nothing happened.
• team members can share changes / branches between themselves without going through the central server.
• You can expose subset of your repository to different groups (let's say you have the latest and greatest feature you do not want exposed to outside contractors who still need to access 'a' repository with the same base code.
• A user can commit his changes into his local repository and keep it local until he is satisfied with it (and can possibly rework the history to make it cleaner before pushing)
• In general, the fact that you have the whole repository locally make some operations more efficient, especially when looking at the log, comparing files in history...etc.

And I am sure much more possibilities. It all depends really the environment you work in and what feature you may want to use.

Yes, you can use DVCS exactly like centralized, and mostly all you will gain is speed, but taking full advantage of DVCS requires a change in the way you think about version control.

A good question to ask is, "If I could have as many branches as I wanted, commit as often as I wanted, and only share those branches and commits with exactly whom I want, what would I do with it?"

As an example of "as many branches as you want," I currently have around 5 branches just for me. One is the master branch I use for merges to share with colleagues. One is for the task I'm currently working on. One is for a previously finished task that I'm waiting for colleagues to review. Two are for longer-term tasks that I started, but had to postpone due to schedule priorities and will pick up again after the next release.

As an example of the benefits of "commit as often as you want," a colleague today made a bunch of small changes from a static analysis tool, making about 15 local commits where only one would be done with CVCS. He accidentally introduced a serious bug that he didn't detect until he was done, but by using git bisect was able to quickly narrow it down.

As an example of "exactly whom I want," consider two developers working on a feature together. They need to share frequently, but often what they share would break the main build. With DVCS they can pull only from each other without sharing with everyone, and then check in a fully working feature in one cohesive push. Another example is the long-term task I had to postpone. If my boss decides to hand that task to someone else who has freed up, I can easily give him my partially completed work with all its history.

If your colleague changes one file, and commits the change, then you change another file without knowing about your colleague's commit, SVN will allow your commit, but Hg and git will not. This is by design because hg and git track the state of your entire repository, whereas SVN tracks changes to individual files and folders.