Tu as intégré ce nouveau paradigme et tu as confiance en lui car il s'appuie sur une théorie mathématique dans laquelle tu baignes.
C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
Pour beaucoup, le modèle conceptuel derrière Mercurial (des sous graphes connexes en quelque sorte) interpellait les afficionados de Git.
Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
Mais même si c'est mal nommé le terme de "branche" est couramment admis.
En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
Dans les mal nommés "branching patterns", on parle de branchement par release.
Avec un DVCS on peut imaginer 2 moyens pour maintenir des variantes:
- S'appuyer sur des forks (un par variante) auquel cas la notion de branche perd tout sens
- Faire cohabiter les 2 variantes dans un même repo. Il faut donc mettre en place un mécanisme pour les matérialiser.
Le modèle de base de Hg correspond au premier et perturbe les utilisateurs git (alors que git peut aussi le supporter en conservant une branche unique).
Donc oui ce n'est pas "absolument" indispensable mais confortable tout de même et fort heureusement Pijul le supporte.
Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.
[^] # Re: Soit j'ai rien compris soit...
Posté par El Titi . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 6.
Tu as intégré ce nouveau paradigme et tu as confiance en lui car il s'appuie sur une théorie mathématique dans laquelle tu baignes.
C'est très bien mais sois un peu indulgent et accorde un peu de temps aux autres qui découvrent.
Pour beaucoup, le modèle conceptuel derrière Mercurial (des sous graphes connexes en quelque sorte) interpellait les afficionados de Git.
Je saisis mieux cette notion de sous-ensemble dans lequel, le point central est que l'ordre n'a plus d'importance (sauf en cas de dépendance).
Mais même si c'est mal nommé le terme de "branche" est couramment admis.
En GCL (pardon de répéter ce gros mot) le terme consacré est variante pour ne pas présumer de la solution technique retenue.
Par exemple, on gère une variante pour la version (configuration :) que l'on maintient et une pour le dev en cours.
Dans les mal nommés "branching patterns", on parle de branchement par release.
Avec un DVCS on peut imaginer 2 moyens pour maintenir des variantes:
- S'appuyer sur des forks (un par variante) auquel cas la notion de branche perd tout sens
- Faire cohabiter les 2 variantes dans un même repo. Il faut donc mettre en place un mécanisme pour les matérialiser.
Le modèle de base de Hg correspond au premier et perturbe les utilisateurs git (alors que git peut aussi le supporter en conservant une branche unique).
Donc oui ce n'est pas "absolument" indispensable mais confortable tout de même et fort heureusement Pijul le supporte.
Ce que je comprends de tes interventions par contre, c'est qu'un autre branching pattern est en grande partie rendu caduc: Le branchement par feature.
C'est là où je pense qu'il serait utile de développer à d'autres occasions. Mais je crois que je vais m'y atteler car ça m'intéresse de creuser.