It's been a while since I wrote my Git for Eclipse users post. (It's now been uploaded to the EGit Wiki, so hopefully it will appear as part of the user documentation as well.) Thanks to those of you who reached out to me, directly or indirectly, with feedback. One of the recurring themes of the comments was regarding the lack of a central version control system:
- ☞ There is no master repository
It's an implicit property of a centralised version control system that there is a master repository. In a distributed version control system, each user has a full copy of the repository; so theoretically, any user can be the master.
However, in practice, there's usually a de-facto master repository. Most of the time, this is the one that is coupled to the build system; after all, there is usually a central build system generating released artefacts, even if the version control system could be from anywhere.
In a corporate or large organisation, it's also fairly likely that the build system (and local storage) will be on some kind of backed up server, connected to RAID backed drives and other redundant server configuration. In fact, this isn't that different from an existing centralised version control system, where the code is hosted from a backed up location.
So, just because you're using a distributed version control system doesn't mean that you can't have a centralised repository. In fact, it often makes sense to have one; that is where the developers synchronise their code to, build and release from, and acts as a public log of whatever has happened to the repository.
In EGit's case, there are many copies of the repository. I have a few local copies; there are many co-ordinated via Gerrit; others exist on GitHub, but ultimately there is one place where all changes end up: git://egit.eclipse.org/egit.git. That's what's used in the build server, and ultimately, the http://download.eclipse.org/egit/updates/ update site. You should be able to download 0.7 in time for EclipseCon.
So, while there may not need to have a central repository, in practice, the one connected to the build system (and hosted on redundant/backed up hardware) is often the canonical repository.