Merci pour ta tentative d'explication bien argumentée, mais j'avoue que j'ai toujours du mal à comprendre.
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.
C"est encore plus simpliste que ça. Il s'agit d'une bête séquence linéaire de révision complète. Les branches et tag son simplement des recopies de sous-arborescence. Il n'y a pas de graphes (DAG) à proprement parler.
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à.
Oui c'est l'histoire des piquets et des barrières mais je ne vois pas ce que ca change.
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.
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit. Si tu as A->B et A->C et que tu veux réconcilier les modifs concurrentes de C avec B, tu dois, soit créer une revision C qui gère tes conflits, soit appliquer le patch C dans ton workspace et commiter un patch D après résolution. Avec git&Co, on a A->B, A->C, B->D et C->D
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
Pourtant c'est utile de conserver ce lien C->D pour éviter de réappliquer ce patch lors d'un futur merge éventuel entre ces 2 branches. C'est ce qu'on appelle la mémoire de merge.
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.
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Ensuite après ton pull, tu te retrouves quand même avec plusieurs heads (la tienne et la sienne) et il faut bien faire un resolve pour arbitrer les conflits.
Mercurial/Monotone fonctionnent comme ça de base aussi. quand à Git mis à part qu'une branche ne peut avoir qu'une head et qu'il faut les nommer ou qu'elles suivent des conventions (remote) il n'y a rien de plus à faire. Un conflit est un conflit et il faut le résoudre, non ?
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
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
Chaque approche a ses avantages et ses inconvénients, on en a déjà un peu parlé ici. http://linuxfr.org//comments/1125043,1.html
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
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.
En gros le fait que le pull du repository et l'update de ton répertoire local soient 2 opérations différentes te gène.
Ca ne ma parait être un critère de décision primordial.
Aux dernières nouvelles, les perfs de darcs étaient bien en deçà de ses concurrents. Ca a changé depuis ?
[^] # Re: Lapin compris
Posté par El Titi . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 2.
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.
C"est encore plus simpliste que ça. Il s'agit d'une bête séquence linéaire de révision complète. Les branches et tag son simplement des recopies de sous-arborescence. Il n'y a pas de graphes (DAG) à proprement parler.
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à.
Oui c'est l'histoire des piquets et des barrières mais je ne vois pas ce que ca change.
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.
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit. Si tu as A->B et A->C et que tu veux réconcilier les modifs concurrentes de C avec B, tu dois, soit créer une revision C qui gère tes conflits, soit appliquer le patch C dans ton workspace et commiter un patch D après résolution. Avec git&Co, on a A->B, A->C, B->D et C->D
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
Pourtant c'est utile de conserver ce lien C->D pour éviter de réappliquer ce patch lors d'un futur merge éventuel entre ces 2 branches. C'est ce qu'on appelle la mémoire de merge.
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.
Le cherry picking , ce n'est pas propre à darcs. Tous les DVCS le gèrent et même SVN le fait (mal car pas de merge cylciques).
Ensuite après ton pull, tu te retrouves quand même avec plusieurs heads (la tienne et la sienne) et il faut bien faire un resolve pour arbitrer les conflits.
Mercurial/Monotone fonctionnent comme ça de base aussi. quand à Git mis à part qu'une branche ne peut avoir qu'une head et qu'il faut les nommer ou qu'elles suivent des conventions (remote) il n'y a rien de plus à faire. Un conflit est un conflit et il faut le résoudre, non ?
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
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
Chaque approche a ses avantages et ses inconvénients, on en a déjà un peu parlé ici.
http://linuxfr.org//comments/1125043,1.html
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
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.
En gros le fait que le pull du repository et l'update de ton répertoire local soient 2 opérations différentes te gène.
Ca ne ma parait être un critère de décision primordial.
Aux dernières nouvelles, les perfs de darcs étaient bien en deçà de ses concurrents. Ca a changé depuis ?