Actions

Dvcs

From Joomla! Documentation

Revision as of 15:43, 28 June 2010 by Dukeofgaming (Talk | contribs)

Contents

Why

Using distributed version control means that everyone has a repository, so anyone can be a server and a client. Unlike with centralized version control systems one has the freedom and flexibility of having one's own local repository (without having to connect to a server), using it (committing, without having to connect to a server), and synchronizing it with other repositories later, with ease and regardless of the number of branches there might be.

The distributed nature of these systems allow to handle conflicts more intelligently and adapt to more complex workflows without hassle, and with free hosting services for this kind of repositories (such as bitbucket.org, github.com and launchpad.net), everyone can exchange code in any direction, without needing to create patches.

The typical setup of a centralized system such as CVS and Subversion involve a server with a repository and users as clients that push and pull the changes remotely. Everyone must be in tone with the same repository at the same time.

CentralizedVCS.png

In a DVCS setup there is often also a server that has a central repository where everyone pushes changes, however this time, each one of the clients has its own local repository (to which they commit their changes), so they only need to connect to the centralized server with the central repository when sharing the changes, in other words, everybody has a repository they work with and then synchronize with a central repository. Now commits and updates happen locally, and repository synchronization through push/pull is the only thing one needs to be connected for.

DistributedVCS.png

But because anyone with a repository can also act as server in a distributed model, peers can push/pull between themselves, and this allows people to cluster in teams and then integrate their changes with other teams. The following diagram denotes what would happen in a LAN/VPN environment using a DVCS.

DistributedVCS Complex.png

There is no need for commit access, one commits locally and authorization only happens when writing to or reading from other repositories.

The Joomla! community can benefit from this kind of tools because collaboration turns out to be more accessible fluent and without others stepping on anyone's toes while committing changes, and also, Joomla! can get more contributors and be more visible to developers through services like github and bitbucket.

Pros

  • One can use version control locally (i.e. actual committing) without polluting a central repository for everyone else.
  • One can use version control offline.
  • Merging branches is trivial (under 5 minutes), since the DVCS stores richer metadata and handles more conflicts.
  • IDE and graphical integrations for this tools are mature and widely available.
  • Free quality hosting services for repositories (bitbucket.org, github.com, launchpad.net).
  • Contributing to a project is easier (see nest point).
  • Cherry-picking (i.e. pulling) changes from anyone instead of waiting for patches, no need for the contributors to build and send them (although they can still do it).

Cons

  • Learning curve can be bumpy at start (more if one is biased with a centralized VCS).
  • The rest of your team must be willing to adopt the tool.

DVCS comparison

Git

Pros

  • Has github.com, probably the most prominent online service of its type
  • Lots of advanced utilities

Cons

Mercurial

Pros

Cons

Bazaar

Pros

Cons

Action Plan