Déjà, il faudrait être bien sur qu'un DSCM est ce qui est le mieux adapté à tes besoins. Les DSCM deviennent à la mode mais posent également des problèmes d'organisation. Ce n'est plus le logiciel qui centralise, mais une personne : tout le monde doit en être conscient. Il y a des projets vraiment communautaires, ou simplement avec plusieurs mainteneurs de "même poids", qui n'accepte pas cette philosophie. L'autre point, technique, est qu'avec un DSCM, tu auras plus de conflits à gérer qu'avec un SCM classique. Chaque personne pouvant faire sa sauce chez lui, cela complique les fusions de code.
Cela dit, que choisir entre Git et Mercurial ?
C'est probablement plus une affaire de gout qu'autre chose.
Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.
La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.
Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
Mes 2 centimes
Déjà, il faudrait être bien sur qu'un DSCM est ce qui est le mieux adapté à tes besoins. Les DSCM deviennent à la mode mais posent également des problèmes d'organisation. Ce n'est plus le logiciel qui centralise, mais une personne : tout le monde doit en être conscient. Il y a des projets vraiment communautaires, ou simplement avec plusieurs mainteneurs de "même poids", qui n'accepte pas cette philosophie. L'autre point, technique, est qu'avec un DSCM, tu auras plus de conflits à gérer qu'avec un SCM classique. Chaque personne pouvant faire sa sauce chez lui, cela complique les fusions de code.
Cela dit, que choisir entre Git et Mercurial ?
C'est probablement plus une affaire de gout qu'autre chose.
Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.
La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.
Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
[ Répondre ]