Si tu prends subversion, le graphe qui est considéré c'est un graphe où les sommets sont des révisions et les arcs veulent dire "est la révision suivante de", et le graphe ne peut former qu'une ligne.
Pour git/mercurial/bazaar, c'est pareil mais la différence est que le graphe est un graphe acyclique, càd qu'une révision peut avoir deux "révisions précédentes". C'est ce qui arrive quand on fusionne deux branches. Dans ce cas il y a un deuxième type de sommet qu'on pourrait appeler "point de fusion". Donc au moins on peut dire que git/mercurial/bazaar ont "conscience" de l'existence des branches, pas comme subversion.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de besoin de faire un patch qui résout les conflits, tu ne vois pas de trace de ta fusion.
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes. Git s'en sortait mieux, il a une notion de "fast-forward" qui crée automatiquement ce point de fusion quand tout va bien, ça qui évite de devoir toujours faire comme avec mercurial et bazaar.
Résumé : darcs est plus simple à utiliser car il implémente la notion intuitive de "ce changement-ci dépend de ce changement-là".
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 4.
Pour git/mercurial/bazaar, c'est pareil mais la différence est que le graphe est un graphe acyclique, càd qu'une révision peut avoir deux "révisions précédentes". C'est ce qui arrive quand on fusionne deux branches. Dans ce cas il y a un deuxième type de sommet qu'on pourrait appeler "point de fusion". Donc au moins on peut dire que git/mercurial/bazaar ont "conscience" de l'existence des branches, pas comme subversion.
Pour darcs, le graphe qui est considéré a pour sommets des patchs, et les arcs signifient "dépend de". Par exemple, si un patch A qui modifie des lignes qui ont été au préalable modifiées par un patch B, alors A dépend de B. Et on a une partie du graphe qui est : A -> B. Donc par exemple si A répare un bug, tu sais que pour obtenir A tu dois obtenir B si tu ne l'as pas déjà.
Autant dire que pour un même projet avec des mêmes "commits", le graphe de darcs a, en général, moins d'arcs que le graphe de git par exemple.
Premier intérêt, ça permet de facilement récupérer un patch d'une branche à l'autre. Tu as ta branche de développement de ton projet et tu as la branche de ta release en préparation. Si dans la branche de développement quelqu'un a mis un patch intéressant (qui résout un bug, etc.) que tu veux faire passer dans la branche release, c'est juste une histoire de faire un pull. (On appelle ça le "cherry-picking"). Si c'est un patch qui dépend de rien d'instable, ça se passe bien.
Deuxième intérêt, ça permet de faire des branches et des fusions sans s'en rendre compte et surtout, sans avoir besoin d'apprendre les concepts de branches et de fusions. Tu peux voir chaque dépôt darcs comme une branche et chaque pull ou push comme une fusion. Ça se voit dans l'interface de darcs, y'a pas de commande à la "git checkout" ou "git branch". De même dans l'historique, tant que tu n'as pas de besoin de faire un patch qui résout les conflits, tu ne vois pas de trace de ta fusion.
De plus, quand j'avais testé mercurial et bazaar, la fusion de deux branches nécessitait de taper des commandes supplémentaires même quand les modifications étaient indépendantes. Git s'en sortait mieux, il a une notion de "fast-forward" qui crée automatiquement ce point de fusion quand tout va bien, ça qui évite de devoir toujours faire comme avec mercurial et bazaar.
Résumé : darcs est plus simple à utiliser car il implémente la notion intuitive de "ce changement-ci dépend de ce changement-là".