Re: Git & Mercurial

La raison pour laquelle j'utiliserai git c'est gerrit (en action chez la
team androïd [1]) et github.
Je refais la pub pour le blog de Cédric[2] car à le lire, il m'a convaincu.
Malheureusement c'est seulement passé de ma whynotlist à la wishlist et pas
encore dans ma todolist le peu que j'ai utilisé


Affaire à suivre.

[1] https://review.source.android.com
[2]http://beust.com/weblog/2010/04/06/git-for-the-nervous-developer/

2010/10/13 Antoine DESSAIGNE <[email protected]>

> 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)
>