From Joomla! Documentation

Revision as of 08:31, 16 July 2010 by Dukeofgaming (Talk | contribs)


What is a DVCS?

Using distributed version control means that everyone is able to commit without affecting others, and this is the case because everyone has a personal repository. In a distributed model like this, anyone can be a server and a client. Imagine SVN gone P2P.

In more concrete words, you do not need to connect to a server to commit, committing is personal, and until you are sure you have the final version you then share your changes, but what really matters is that, along the way, versioning was helpful to you and not intrusive to everyone else, in a centralized system you would have to pollute everyone's code to achieve that convenience, but with a distributed system you no longer face the "to commit or not to commit" dilema. You can even commit offline.

The distributed nature of these systems make them need to gather more data about the changes in the files, specially branches, and this allows the DVCS to handle conflicts more intelligently and adapt to more complex workflows without hassle. In a DVCS everyone is a different branch, so branch merging is a thing that happens extremely often and mostly without conflicts.

Today there are lots of services such as (Mercurial), Google Code (Mercurial) (Git), (Git) and (Bazaar), allows everyone to get a public repository that anyone can see, that anyone can fork (i.e. checkout, clone), and more importantly, that anyone can contribute to by simple social dynamics.

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, if they want to commit.


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 central repository when feeling like sharing the changes. Now commits and updates happen locally, and repository synchronization through push/pull is the only thing one needs to be connected for.


But because anyone with a repository can also act as server in a distributed model like this, 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, when each person opens up their local repository.

DistributedVCS Complex.png

There is no need for commit access for local repositories, one commits locally and authorization only happens when writing to or reading from other repositories. IDE and graphical integrations for DVCSs are mature and widely used.

Why would Joomla! benefit from it

The Joomla! community can benefit from this kind of tools because collaboration turns out to be more accessible, fluent and open. This way Joomla! can get more contributors and be more visible to developers through services like github and bitbucket.

After laying out in the previous section the kinds of setups there can be, the following diagram shows what actually happens in the real life of an open source project:


  • ...


  • Merging branches is trivial (under 5 minutes), so the work of integrators get easier.
  • Development teams can handle their own merging.
  • Easier for outsiders to step in and contribute thanks to services like and
  • No need for contributors to build patches, once they are finished, they can just ask others to pull from their repository.
  • A more open development process for everyone.


  • Grasping the distributed model represents somewhat of a learning curve.
  • Everyone must be willing to adopt the tool.

DVCS comparison



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


  • Hard to learn
  • Poor Windows support



  • Easy to learn
  • Great Windows support
  • Has Google Code and


  • Short in advanced comands in comparison with git (for example, git rebase)




Action Plan