A central server is, of course, still desirable with a DVCS if you're working with other people. But, the purpose of that server is completely different than in centralized VCSes. It is simply a hub that allows all developers to share their changes in a single place, rather than pull and push between each other's repositories. Such a single central repository (often called upstream also) serves as a backup for all the changes tracked in the individual repositories of all the following team members.
Different approaches can be applied to sharing code with the central repository in a DVCS. The simplest one is to set up a server that acts like a regular centralized server, where every member of the project can push his/her changes into a common stream. But this approach is a bit simplistic. It does not take full advantage of the distributed system, since people will use push and pull commands in the same way as they would with a centralized system.
Another approach consists of providing several repositories on a server with the following different levels of access:
- Unstable repository: This is where everyone can push changes.
- Stable repository: This is read-only for all members, except the release managers. They are allowed to pull changes from the unstable repository and decide what should be merged.
- Release repositories: These correspond to the releases and are read-only.
This allows people to contribute and managers to review the changes before they make it to the stable repository. But depending on the tools used, this may be too much of an overhead. In many distributed version control systems, this can also be handled with a proper branching strategy.
Let' take a look at centralized and distributed version control systems.