Ç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)
Oui mais même lorsqu'il n'y a pas de conflit, un système qui s'appuie sur des révisions gère/peut gérer aussi efficacement les changeset que les systèmes basés sur les patchs ala darcs ou Arch.
Avec la surcouche UCM de Clearcase par exemple tu as un système équivalent au merge: le deliver. tu peux choisir de reporter sélectivement un ou plusieur changeset et il y a une détection automatique si 1 changeset dépend de l'application d'un autre. Ca n'a rien à voir. A partir du moment moment où 2 révisions successives sont rattachées logiquement à un changement, c'est complètement équivalent à rattacher un diff à ce même.
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.
Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
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.
Tu n'es pas obligé de les connaitre les 2 ni de les utiliser: le projet Mercurial en lui-même a choisi la même approche que toi pour son propre hébergement. Mais comme déjà indiqué chaque technique a ses propres avantages et inconvénients.
Je trouve rassurant de pouvoir changer d'approches lorsqu'on en a besoin.
Réfère toi à ce blog si tu veux plus d'infos pour comprendre les différences entre chaque approche. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)
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.
cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.
[^] # Re: Lapin compris
Posté par El Titi . En réponse au journal Appel aux testeurs Windows pour Darcs 2.4.4. Évalué à 2.
Ç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)
Oui mais même lorsqu'il n'y a pas de conflit, un système qui s'appuie sur des révisions gère/peut gérer aussi efficacement les changeset que les systèmes basés sur les patchs ala darcs ou Arch.
Avec la surcouche UCM de Clearcase par exemple tu as un système équivalent au merge: le deliver. tu peux choisir de reporter sélectivement un ou plusieur changeset et il y a une détection automatique si 1 changeset dépend de l'application d'un autre. Ca n'a rien à voir. A partir du moment moment où 2 révisions successives sont rattachées logiquement à un changement, c'est complètement équivalent à rattacher un diff à ce même.
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.
Sauf que dans la pratique, reconstruire une révision de ton arborescence nécessite de recalculer tous les patchs en dépendance. Les performances s'en ressentent par rapport aux autres pour un avantage conceptuel à restant à démontrer.
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.
Tu n'es pas obligé de les connaitre les 2 ni de les utiliser: le projet Mercurial en lui-même a choisi la même approche que toi pour son propre hébergement. Mais comme déjà indiqué chaque technique a ses propres avantages et inconvénients.
Je trouve rassurant de pouvoir changer d'approches lorsqu'on en a besoin.
Réfère toi à ce blog si tu veux plus d'infos pour comprendre les différences entre chaque approche.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me(...)
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.
cf. mon lien: problèmes de perfs, pbs d'intégration dans les IDE.