Re: Git & Mercurial

Le 13 octobre 2010 12:34, Frederic Camblor <[email protected]> a écrit :

> Bonjour tous !
>
> Moi, ya une grosse question que je me pose sur les DVCS : pourquoi tout le
> monde dit que les fusions de branches "c'est mieux qu'avant" ?
>
> Je veux dire... tous les outils se basent sur des diffs non ?
>
> Et les problèmes des merges c'est :
> - J'ai un conflit lors de mon merge => mais là, je pense pas qu'un DVCS va
> être plus à même de résoudre les conflits ... peut-être diminuer sa
> probabilité d'apparition du fait de commits "encore plus fréquents" (donc
> diffs "plus petits") dû au repository local (qui fait qu'on peut commiter en
> local, même si des tests passent pas ou, pire, que le code compile pas) ?
> - Je sais pas quel commit a été reporté sur quelle branche => la
> fonctionnalité de "cherry pick" chez GIT (je suppose qu'il doit y avoir un
> équivalent chez Mercurial ?), et également, plus récemment, le merge
> tracking chez Subversion (>= 1.5).
>
> Je ne connais les DVCS qu'à travers ce que j'en lis à droite à gauche, mais
> mon interrogation reste entière à l'heure d'aujourd'hui !
> Alors .. suis-je passé à coté de quelque chose ?
>
> Fred
>

Alors pour répondre (et si je ne dis pas de bêtises), effectivement ce n'est
pas le coté "distribué" qui évite les problèmes de merge, c'est la gestion
des révisions qui le fait. A priori, quand on merge des révisions, SVN
essaye de deviner ce qui a été fait entre les deux révisions tandis que Git
et Mercurial se souviennent de chaque étape.

De plus, chacun des deux outils affiche nativement l'arborescence des
branches lorsqu'on affiche l'historique. Ce qui est nettement plus pratique
pour savoir ce qui a été mergé et ce qui ne l'est pas..

Par ailleurs, comme SVN ne gère pas bien les merges, on se retrouve à bosser
directement dans le trunk. Et comme toutes les fonctionnalités ne se
développent pas en 2 jours il est courant d'avoir plus de 2 semaines entre
le début du code et le commit pour éviter de gêner les autres. Du coup, on
n'utilise pas réellement SVN comme un gestionnaire de source mais plus comme
un répertoire partagé...

Sinon j'ai l'intention de tester réellement les capacités de merge mais je
souhaitais d'abord faire ma pré-sélection entre Git et Mercurial. Je vous
tiendrai au courant des résultats.

Pour revenir à Eclipse, j'ai toujours été curieux du process utilisé pour
choisir si tel ou tel VCS. Ils étaient bloqués sur CVS alors que plus
personne ne l'utilise (ou presque) et là ils semblent passer à Git... Et à
priori la raison pour laquelle ils ont choisi Git c'est car il y a une
implémentation en Full Java. Mais subversion en a aussi une donc je ne sais
pas trop quoi penser.

Antoine.
(qui est toujours intéressé par d'autres retours)