Ces derniers présentent en effet beaucoup d'avantages par rapport à l'ancienne génération représentée par subversion, et en dresser la liste dépasse totalement le cadre de ce billet.

Il m'est cependant possible de dire que ces avantages font qu'aujourd'hui ces logiciels, dont les plus représentatifs actuellement sont Mercurial et Git, ont progressivement remplacé l'ancienne génération, jusqu'à presque complètement les détrôner.

Et c'est la raison pour laquelle, en 2009, le choix de subversion n'a pas été forcément compris, autant à l'intérieur qu'à l'extérieur de la communauté des contributeurs.

Or, suite à l'arrêt du développement de PHP 6, le processus de développement de PHP est en train d'évoluer en profondeur.

Certains ont donc saisi cette occasion pour proposer sur internals@, la liste de diffusion des contributeurs, de changer une nouvelle fois de logiciel de gestion de versions au profit d'un DVCS.

Les premières réactions ont été plus que mitigées, mais heureusement, cela n'a pas découragé les promoteurs de cette migration, et le sujet est revenu depuis régulièrement sur le tapis, à tel point que le 30 juillet dernier, une RFC portant sur ce sujet a été proposée.

Et depuis son dépôt, le débat fait rage sur internals@, et il est bien difficile de prédire ce qu'il en ressortira.

En effet, certains contributeurs ne voient aucun intérêt à utiliser un DVCS, d'autres n'en comprennent pas le concept et la philosophie et d'autres encore s'inquiètent des répercussions que pourraient avoir la multiplication de dépôts de code non officiel, voir même de la compatibilité de la licence du langage, qui empêche l'utilisation du nom PHP, avec un tel outil.

D'autant que comme d'habitude sur internals@, il y a parfois une bonne dose de mauvaise foi dans les discussions, et il arrive que des contributeurs argumentent uniquement pour protéger leurs intérêts.

Pour autant, il est probable que PHP utilisera à moyen terme un DVCS car l'essentiel du débat porte sur le choix du logiciel qui sera utilisé et sur la façon de l'utiliser, plutôt que sur la pertinence d'utiliser un tel outil.

Reste donc aux contributeurs à se décider entre Mercurial et Git, puisqu'il semble que ce soit les deux options envisagées le plus sérieusement, et à définir la façon dont ils s'en serviront, ce qui semble être de loin le plus facile.