Actions

Difference between revisions of "Dvcs"

From Joomla! Documentation

(Git)
m (Public Repository Hosting)
(31 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
=Why=
 
=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.
+
==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.
  
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.
+
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''', you don't need to refrain from committing, at all; in a centralized system you would have to pollute everyone's code to achieve that level convenience, but with a distributed system you no longer face the "to commit or not to commit" dilema, you commit when you want to share all your changes. You can even commit offline. In a DVCS everyone represents a different branch, so branch merging is a thing that happens extremely often and mostly without conflicts, at all.
  
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.
+
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 (meaning getting around conflicts automatically) and adapt to more complex workflows without hassle, take for instance how Mootools development looks before and after switching to git (thumbnails at right).
 +
 
 +
[[Image:Mootools_bg.PNG|thumb|Mootools before git, development was linear, changes must happen one after another]][[Image:Mootools_ag.PNG|thumb|Mootools after git, changes happen when they naturally happen.]]
 +
 
 +
 
 +
Today there are lots of services such as bitbucket.org (Mercurial), Google Code (Mercurial) github.com (Git), gitorious.org (Git) and launchpad.net (Bazaar), that allow 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.
  
 
[[Image:CentralizedVCS.png]]
 
[[Image: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.
+
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 own 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.
  
 
[[Image:DistributedVCS.png]]
 
[[Image: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.
+
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.
  
 
[[Image:DistributedVCS_Complex.png]]
 
[[Image: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.
+
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.
  
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.
+
==Why would Joomla! benefit from this==
  
==Pros==
+
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.
* One can use version control locally (i.e. actual committing) without polluting a central repository for everyone else.
+
 
* One can use version control offline.
+
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), since the DVCS stores richer metadata and handles more conflicts.
+
 
* IDE and graphical integrations for this tools are mature and widely available.
+
[[Image:OpenSourceProjectScenario.png]]
* Free quality hosting services for repositories (bitbucket.org, github.com, launchpad.net).
+
 
* Contributing to a project is easier (see nest point).
+
* Contributors can step in immediately, since:
* 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).
+
** All they would need is to fork the project from the official Joomla repository in a service like bitbucket.org or github.com
==Cons==
+
** No need for them build patches, once they are finished, they can just ask others to pull from their repository.
* Learning curve can be bumpy at start (more if one is biased with a centralized VCS).
+
* A more open development process for everyone.
* The rest of your team must be willing to adopt the tool.
+
* Contributors can team up and handle their own merging, thus giving greater quality contributions in the end.
 +
* Less work for integrators (merging branches is trivial (under 5 minutes))
 +
* Contributors can have their own branches without affecting others' (but being able to share them if necessary).
 +
* ...
 +
 
 +
However, there are some potential problems:
 +
 
 +
* Grasping the distributed model represents somewhat of a learning curve (unbiasing oneself from CVS/SVN is a general recommendation).
 +
* Everyone must be willing to adopt the tool.
 +
* ...
 +
 
 +
==Additional Reading Material==
 +
* [http://zef.me/3369/how-git-encourages-open-source-contribution How Git Encourages Open Source Contribution]
 +
* [http://hginit.com/00.html Subversion Re-education]
 +
* [http://tuxychandru.blogspot.com/2010/01/how-git-shines-above-subversion-at.html How Git shines above Subversion at Merging]
  
 
=DVCS comparison=
 
=DVCS comparison=
 +
 +
Aspects taken into account to consider both git and Mercurial:
 +
 +
* IDE Compatibility
 +
* 3rd party hosting
 +
* MacOS Compatibility
 +
* Windows Compatibility
 +
* Linux Compatibility
 +
* Shell integration
 
==Git==
 
==Git==
 +
===OS Binaries===
 +
* [http://git-scm.com/download Linux, MacOS X & Solaris]
 +
* [http://code.google.com/p/msysgit/downloads/list Windows]
 +
===Shell Integration===
 +
* [http://code.google.com/p/tortoisegit/ TortoiseGit]
 +
===IDE Integration===
 +
* [http://www.eclipse.org/egit/ EGit (Eclipse)]
 +
* [http://nbgit.org/ Netbeans]
 +
===Patching procedure===
 +
* [http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ How to create and apply a patch with Git]
 +
===Where to start===
 +
* [http://progit.org/book/ Pro Git]
 +
===Public Repository Hosting===
 +
* [https://github.com/ github]
 +
* [http://gitorious.org/ Gitorious]
 
===Pros===
 
===Pros===
 
* Has github.com, probably the most prominent online service of its type
 
* Has github.com, probably the most prominent online service of its type
 
* Lots of advanced utilities
 
* Lots of advanced utilities
 
 
===Cons===
 
===Cons===
* Hard to learn
+
* Harder to learn
* Poor Windows support
+
* Not official (but well maintained) and quirky Windows support
 
+
 
==Mercurial==
 
==Mercurial==
 +
===OS Binaries===
 +
* [http://mercurial.selenic.com/downloads/ Linux, MacOS X, Solaris & Windows]
 +
===Shell Integration===
 +
* [http://tortoisehg.bitbucket.org/ TortoiseHg]
 +
===IDE Integration===
 +
* [http://www.eclipse.org/egit/ EGit (Eclipse)]
 +
* Netbeans (built-in)
 +
* JetBrains PhpStorm (built-in since 2.0 or plugin for 1.0)
 +
===Patching procedure===
 +
* [http://shampavman.wordpress.com/2009/10/13/mercurial-patches-how-to/ Mercurial, Patches -How to?]
 +
* [http://davidherron.com/blog/topics/972-using-mercurial-patch-queues Using Mercurial patch queues]
 +
* [http://mercurial.selenic.com/wiki/MqExtension Mercurial Queues Extension]
 +
===Where to start===
 +
* [http://hginit.com/ Hg init]
 +
* [http://mercurial.selenic.com/wiki/QuickStart Quick Start]
 +
===Public Repository Hosting===
 +
* [http://www.bitbucket.org/ bitbucket]
 +
* [http://code.google.com/projecthosting/ Google Code Project Hosting]
 +
 
===Pros===
 
===Pros===
 +
* Easy to learn
 +
* Good Windows support (works the same in al OSs)
 +
* Has Google Code and BitBucket.org
 
===Cons===
 
===Cons===
==Bazaar==
+
* Short in advanced comands in comparison with git (for example, '''git rebase''')
===Pros===
+
 
===Cons===
+
==The case for Joomla==
 +
Git is probably the most popular DVCS to date, however, it has a relative weakness that sets it appart from Mercurial: its Windows support is not as good and straight forward.
 +
 
 +
The possibility for adopting both DVCSs [http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/d081a43545ce3cc6/e49276cf5a88585a?q=git+support+joomla#e49276cf5a88585a was discussed in the mailing list] for the reason that it is possible for Mercurial users to push to a git repository in a lossless fashion [http://hg-git.github.com/ thanks to a plugin developed by the guys at github]. Since both Git and Mercurial communities are big enough, the project would be lowering the barrier to an even broader contributor audience.
 +
 
 +
===Logistics===
 +
 
 +
* Core Repository within JoomlaCode
 +
* Official repositories in Github and Bitbucket
 +
* ...
 +
 
 +
====Patching====
 +
...
 +
 
 +
===Tutorials===
 +
* [[Contributing through git and mercurial]]
 +
* [[Starting with git]]
 +
* [[Starting with Mercurial]]
 +
* [[Integrator's guide]]
 +
 
 
=Action Plan=
 
=Action Plan=
 +
[[Category:Working Groups]]
 +
 +
* [http://groups.google.com/group/joomla-dev-framework/browse_thread/thread/d081a43545ce3cc6/f6c9ffc64c8de31d Use Mercurial for the platform project]

Revision as of 21:30, 14 March 2011

Contents

Why

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, you don't need to refrain from committing, at all; in a centralized system you would have to pollute everyone's code to achieve that level convenience, but with a distributed system you no longer face the "to commit or not to commit" dilema, you commit when you want to share all your changes. You can even commit offline. In a DVCS everyone represents a different branch, so branch merging is a thing that happens extremely often and mostly without conflicts, at all.

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 (meaning getting around conflicts automatically) and adapt to more complex workflows without hassle, take for instance how Mootools development looks before and after switching to git (thumbnails at right).

Mootools before git, development was linear, changes must happen one after another
Mootools after git, changes happen when they naturally happen.


Today there are lots of services such as bitbucket.org (Mercurial), Google Code (Mercurial) github.com (Git), gitorious.org (Git) and launchpad.net (Bazaar), that allow 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.

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 own 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.

DistributedVCS.png

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 this

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:

OpenSourceProjectScenario.png

  • Contributors can step in immediately, since:
    • All they would need is to fork the project from the official Joomla repository in a service like bitbucket.org or github.com
    • No need for them build patches, once they are finished, they can just ask others to pull from their repository.
  • A more open development process for everyone.
  • Contributors can team up and handle their own merging, thus giving greater quality contributions in the end.
  • Less work for integrators (merging branches is trivial (under 5 minutes))
  • Contributors can have their own branches without affecting others' (but being able to share them if necessary).
  • ...

However, there are some potential problems:

  • Grasping the distributed model represents somewhat of a learning curve (unbiasing oneself from CVS/SVN is a general recommendation).
  • Everyone must be willing to adopt the tool.
  • ...

Additional Reading Material

DVCS comparison

Aspects taken into account to consider both git and Mercurial:

  • IDE Compatibility
  • 3rd party hosting
  • MacOS Compatibility
  • Windows Compatibility
  • Linux Compatibility
  • Shell integration

Git

OS Binaries

Shell Integration

IDE Integration

Patching procedure

Where to start

Public Repository Hosting

Pros

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

Cons

  • Harder to learn
  • Not official (but well maintained) and quirky Windows support

Mercurial

OS Binaries

Shell Integration

IDE Integration

  • EGit (Eclipse)
  • Netbeans (built-in)
  • JetBrains PhpStorm (built-in since 2.0 or plugin for 1.0)

Patching procedure

Where to start

Public Repository Hosting

Pros

  • Easy to learn
  • Good Windows support (works the same in al OSs)
  • Has Google Code and BitBucket.org

Cons

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

The case for Joomla

Git is probably the most popular DVCS to date, however, it has a relative weakness that sets it appart from Mercurial: its Windows support is not as good and straight forward.

The possibility for adopting both DVCSs was discussed in the mailing list for the reason that it is possible for Mercurial users to push to a git repository in a lossless fashion thanks to a plugin developed by the guys at github. Since both Git and Mercurial communities are big enough, the project would be lowering the barrier to an even broader contributor audience.

Logistics

  • Core Repository within JoomlaCode
  • Official repositories in Github and Bitbucket
  • ...

Patching

...

Tutorials

Action Plan