Does a Distributed Version Control System really have no centralised repository?

Question

It might seem a silly question, but how do you get a working drectory set up without a server to check out from? And how does a business keep a safe backed up copy of the repo?

I assume then there must be a central repo... but then how exactly is it 'distributed'? I always thought of a server-client (SVN) Vs peer-2-peer (GIT) distinction, but I don't believe that can be correct unless tools like GIT are dependent on torrent-style technology?

Answer 1

Does a Distributed Version Control System really have no centralised repository?

There is no enforced central repository - it is only by convention. Most projects do have a central repository, but each repository is equal in the sense that they have the full history, and can push and pull patches between each other.

One way to think of it is a centralised VCS is fixed in a star topology: one central hub acts as the server with the complete repository, with one or more clients hanging off it. The clients typically only have a copy of the most recent clean checkout, and limited history (if any). So most operations require a round-trip to the server. Branching is achieved by creating branches within the one repository.

In a distributed VCS, there is no limit to the topology of your network. You can theoretically have any shape you like. You can have a separate repository per team or sub-project, and stage commits. You can have a stable repository and an unstable repository, and lots of feature branches, and so on. And there is no client/server distinction - all nodes are equal. Each repository is self-contained and complete, and can push and/or pull changes from any other. To get started, you clone an existing repository (make your own copy to work from), and start making changes. Once you make your first commit, you effectively have a branch. Fortunately, it is usually very easy to merge your changes back when you're done.

But what normally happens is you have one repository which is on a central server, which makes it easier for people to get started, and to keep track of where the latest changes are.

how do you get a working drectory set up without a server to check out from?

Your repository has to start somewhere with a source tree. So there is always a first repository, with the initial series of checkins. Let's say you want to work on Murky. You would clone the repository, which gives you a complete repository of your own, with all the history and checkins. You make some changes (thus creating a branch), and when you're done, you push your changes back, where they get merged. Both systems are acting as peers, and they push and pull changesets between each other.

Both Mercurial and Git keep the repository in a hidden subdirectory, so the one directory tree contains both your working copy (which can be in whatever state you like), and the repo itself.

And how does a business keep a safe backed up copy of the repo?

As above, you simply have a nominated master repository which has all the latest merged changes, and back it up like anything else. You can even have multiple backup repos, or have automated clones on physically separate boxes. In some ways, backing up is easier.

I assume then there must be a central repo... but then how exactly is it 'distributed'? I always thought of a server-client (SVN) Vs peer-2-peer (GIT) distinction, but I don't believe that can be correct unless tools like GIT are dependent on torrent-style technology?

It is not distributed in the sense that different clients have different parts, like peer-to-peer file sharing. It is really just in contrast to the centralised model.

All DVCS repositories are first-class citizens. It becomes a social or managerial question of how to arrange them, rather than a technical issue.

Answer 2

Re: 'torrent-style technology' - you're confusing 2 issues, one of network topology (peer to peer vs. server/client) and one of server authority. This is understandable because the terms are almost identical. But there's nothing about distributed source control that makes any requirements on the network connection model - you could be distributing changesets via email if you prefer. The important thing with distributed version control is that each person essentially runs their own server and merges changes in from the other servers. Of course, you need to be able to get your initial clone from somewhere, and how you know where that 'somewhere' is falls outside of the scope of the system itself. There is no 'tracker' program or anything - typically someone has a public repository somewhere with the address published on a web site. But once you've cloned it, your copy is a full one that is capable of being the basis for someone else's clone.