Pour darcs, c'est essentiel de comprendre que gérer des patchs au lieu de gérer des révisions ça change quelque chose et c'est pas juste une représentation interchangeable avec une représentation orientée révisions.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit.
Quand il y a conflit, il faut créer un nouveau patch de résolution de conflit. Ce que je dis c'est que quand il n'y a pas de conflit (donc quand tout commute) alors il n'y a pas besoin de créer de patch supplémentaire.
Mais sinon l'exemple que tu présente est bon (à part que t'as inversé les flèches par rapport à moi). Sauf:
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
non, on aura pareil que dans ton cas de git: il faut créer un patch D qui dépend de B et de C (càd, qui modifie la même zone sur laquelle B et C sont en conflits).
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).
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
Je peux imaginer que les power users de git habitués au checkout ne s'y retrouvent pas, en tout cas y'a de la demande pour des branches locales:
[^] # Re: Lapin compris
Posté par geh . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 2.
Pour darcs, c'est essentiel de comprendre que gérer des patchs au lieu de gérer des révisions ça change quelque chose et c'est pas juste une représentation interchangeable avec une représentation orientée révisions.
Ça change que le logiciel tient compte du fait que deux patchs commutent*. Dans un tel cas, tu sais que les deux patchs appliqués dans n'importe quel ordre vont donner le résultat. Donc les deux patches sont indépendants, et tu peux annuler, transmettre, récupérer l'un sans l'autre.
(*Exemples de situations où deux patchs commutent: deux patchs qui ne modifient pas les mêmes lignes; un patch qui renomme "foo" en "bar" et un patch qui change des lignes dans "foo". En gros, deux patches qui ne "conflitent" pas commutent)
Je ne vois pas en quoi ca évite de créer des patchs/revisions pour résoudre le conflit.
Quand il y a conflit, il faut créer un nouveau patch de résolution de conflit. Ce que je dis c'est que quand il n'y a pas de conflit (donc quand tout commute) alors il n'y a pas besoin de créer de patch supplémentaire.
Mais sinon l'exemple que tu présente est bon (à part que t'as inversé les flèches par rapport à moi). Sauf:
Avec des patch ala darcs on a A->B, A->C, et B->D c'est ça ?
non, on aura pareil que dans ton cas de git: il faut créer un patch D qui dépend de B et de C (càd, qui modifie la même zone sur laquelle B et C sont en conflits).
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).
Oui mais dans darcs les patchs sont des citoyens de première classe et les dépôts ne sont que des ensembles de patches. Pour l'analogie, je dirais que git/bazaar/mercurial sont autant prévus pour le cherry picking que SVN est prévu pour les branches.
C'est le cas avec Mercurial aussi. Tu peux choisir de nommer des branches ou de travailler avec des clones.
OK, j'ai pas encore eu l'occasion de travailler vraiment avec Mercurial, si ça fait ça c'est intéressant. Mais donc au passage on doit apprendre deux concepts de branches.
J'espère que Darcs propose aussi les branches nommées parce que pour des projets conséquents ce manque me parait rédhibitoire
Y'a 2 réponses possibles à la première partie de ta phrase : "non" parce qu'il n'y a pas de branches dans darcs, mais seulement des dépôts. Càd, un dépôt = un répertoire = une branche. Mais je pourrais répondre quad même "oui" en te disant que tu n'as qu'à nommer chaque répertoire avec le nom qui va bien et ça te fait une branche nommée. Chez moi les branches sont placées dans des répertoires frères.
Je peux imaginer que les power users de git habitués au checkout ne s'y retrouvent pas, en tout cas y'a de la demande pour des branches locales:
http://bugs.darcs.net/issue555
http://lists.osuosl.org/pipermail/darcs-users/2009-July/0205(...)