Changement de dépôt de fichiers pour passage à l'open source
Git, Mercurial, SVN... quoi choisir ?
Orangium utilise Subversion (SVN) depuis maintenant deux ans et nous en sommes très satisfait. Cependant, le passage à l'open source nous mène à changer un peu la structure de notre dépôt, peut-être l'hébergement, etc. C'est donc une bonne occasion de passer en revue les différents systèmes de gestion de versions.
Nos prérequis sont déjà tous remplis par l'utilisation de SVN. Je vais donc me pencher plus spécifiquement sur les différences entre SVN, Mercurial et Git afin d'en tirer les avantages d'un changement. J'ai choisi de comparer ces trois systèmes de façon assez autocratique, en me basant simplement sur les projets open source que j'utilise et les technologies qu'ils emploient. Si un lecteur pense qu'un autre système mériterait d'être inclus dans la comparaison, qu'il le fasse savoir et j'en tiendrai compte si le choix d’Orangium n'est pas déjà arrêté.
Dans les faits, j'aimerais tout de même utiliser un système open source distribué... Voila pour le biais de l'observateur.
Last but not least, nous ne voulons pas être responsable de l'administration et de la maintenance de notre dépôt. Nous choisirons donc une solution hébergée, dont il faudra éventuellement vérifier les possibilités une fois le système choisi.
Données de base
Wikipedia nous fournit de très utiles tableaux comparatifs de fonctionnalités, entre autres sur les données juridiques et techniques sur un échantillon assez exhaustif de systèmes de gestion de versions. Les voici ici édités avec un focus sur les différences afin d'y voir plus clair.
| SOFTWARE | History model | Revision IDs | Network protocols |
|---|---|---|---|
| Git | Snapshot | SHA-1 hashes | Git Server Protocol over TCP or ssh, rsync, HTTP/ HTTPS, email, bundles |
| Mercurial | Changeset | Numbers, SHA-1 hashes | HTTP, custom over ssh, email bundles (with standard plugin) |
| Subversion | Changeset and Snapshot | Numbers | custom (svn), custom (svn) over ssh, HTTP and SSL (using WebDAV) |
| SOFTWARE | File renames | Merge file renames | Signed revisions | Merge tracking | Tags | International Support | Unicode filename support | Supports large repos |
|---|---|---|---|---|---|---|---|---|
| Git | Partial | Yes | Partial | Yes | Yes | Partial | Yes | Yes |
| Mercurial | Yes | Yes | Yes | Yes | Yes | Yes | No | Partial |
| Subversion | Yes | No | No | Yes | Partial | Yes | Yes | Yes |
| SOFTWARE | Keyword expansion | Interactive commits | Partial checkout/clone | Permissions | Timestamp preservation | Custom automatic merge tool |
|---|---|---|---|---|---|---|
| Git | No | Yes | No | execution bit only | No | Yes |
| Mercurial | Yes | Yes | Partial | execution bit only | Yes | non-trivial cases only |
| Subversion | Yes | No | Yes | Partial | Partial | Yes |
Je vous laisse vous référer à la page Wikipedia pour des explications quant aux colonnes. Les trois systèmes considérés possèdent des clients intégrés au shell windows - dont Tortoise, pour lequel j'ai un gros faible car je le trouve très pratique! Je ne sais pas si les projets TortoiseHg et TortoiseGit sont effectivement liés mais les gens de marketing ont parfois raison : on fait confiance à une marque...
Pour et contre
Comme je l'ai dit précédemment, j'aimerais passer à un système distribué. La raison est bien développée dans cette présentation. Le workflow (Git en l'occurrence) offre une hiérarchie des dépôts permettant une inclusion des changements externes dans des dépôts intermédiaires, simplifiant le processus d'intégration de changement fait par des contributeurs tiers. De plus, la possibilité de travailler hors ligne est intéressant vu notre propension au voyage... :)
Autre point contre SVN : le manque de support du merge file rename. Ayant eu un certain nombre de changements dans notre nomenclature depuis l'intégration de SVN, cette fonctionnalité m'aurait fait gagner beaucoup de temps... Et vu que nous aimons le changement, autant s'y préparer !
Pour l'instant, Git tient le haut du pavé... Mais quid de Mercurial ? Le fait que les révisions soient numérotées est un argument en sa faveur... La préservation du timestamp peut s'avérer utile le jour où un bogue devra être traqué... Ce ne sont pas des arguments massues, mais il reste qu'en pensant à long terme cela peut devenir important. Joue encore en faveur de Mercurial la notion de changeset, qui induit un mindshift moins drastique.
Informations prises sur les workflows des différents systèmes[1] et malgré notre respect tout relatif de ces normes, il semble que Mercurial soit notre perle potentielle!
La suite
Il se trouve que notre hébergeur de projets, Assembla, propose ces trois types de dépôts en hébergement gratuit. J'ai donc commencé un projet avec Mercurial aujourd'hui, l'entrée en matière est un peu rude pour quelqu'un habitué à un dépôt centralisé mais les choses sont bien expliquées pour qui prend le temps de s'y pencher. Je vais arrêter ici cet article puisque j'en ai atteint le but : partager ma réflexion dans le choix d'un VCS (Version Control System) en condensant des informations que j'espère utile si vous vous trouvez face à ce choix également. N'hésitez pas à me contacter si vous souhaitez un retour d'expérience. Quant à moi, j'essaierai d'écrire un autre article une fois Mercurial mieux maîtrisé.
Références
- [1] Workflow Git et Mercurial
- Un site qui expose plusieurs façon d'envisager le développement collaboratif












1 Commentaires
Jérémy Lloubes administrateur
Recommandations pour la structure d'un dépot Mercurial (Hg) et autres références sur stackoverflow:http://stackoverflow.com/questions/2367453/recommended-mercurial-repository-folder-structure-for-an-svn-user