C'est exactement la question que je me posais au sujet de ta réponse.
Celui qui dit c'est celui qui y est ? Aucune de mes réponses aux commentaires ici n'a été de mauvaise foi, ou n'a utilisé des exemples caricaturaux. Par contre, le coup des dix développeurs qui touchent la même fonction, il faut avouer que ça n'apporte pas grand chose au débat, on est tous d'accord qu'aucun outil ne va faire de miracle.
Je pense que la dichotomie entre les deux cas que tu décris montre bien en quoi Git transforme ses utilisateurs :
soit était triviales et pijul, git ou svn ne poserait pas de gros problème,
Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier (même si les deux branches ont touché des morceaux très éloignés du fichier), il peut se passer n'importe quoi.
soit était signe de gros problèmes de design et demandais à redévelopper une partie d'une fonctionnalité
Là, on n'est carrément pas d'accord. Bien sûr, n'importe quoi de non-trivial sous Git demande de passer des heures à satisfaire les contraintes techniques de l'outil, de revoir la communication, de mieux former les collaborateurs du projet aux bonnes pratiques, de rendre le workflow plus rigoureux...
Parfois c'est aussi le cas dans d'autres systèmes de contrôle de version, bien sûr. Sauf que quand on travaille ensemble, la plupart des cas ne tombent dans aucune de tes deux catégories.
Dans mon expérience de programmeur et de co-auteur de textes en général, il y a plein de petits cas assez simples, mais pas complètement triviaux non plus. Bien sûr, on peut passer du temps à rebaser, à corriger les merges qui ont mélangé les lignes, à organiser ses branches en workflows. Mais avec un outil plus rigoureux, on pourrait aussi utiliser tout ce temps-là pour travailler sur le projet au lieu de satisfaire Git.
Exemple, dans l'écriture d'un projet comme Pijul, où les co-auteurs se font confiance et travaillent assez indépendamment sans se synchroniser outre mesure, il arrive qu'on ait des problèmes. Pourtant, vu qu'on travaille tous sur plein de sous-projets à la fois (parce qu'il y a beaucoup à faire, et qu'on n'est pas beaucoup), aucun de nous n'a envie d'adopter une structure rigide de branches, des merges temporaires pour vérifier que deux features passent bien ensemble, etc.
Un truc particulièrement difficile dans Pijul est que si on change la sortie d'un algo, il faut adapter tous les algos qui dépendait de cette sortie. Ça fait des gros patchs, mais avec Pijul on s'en sort très bien, je suis certain que Git nous aurait déjà donné du fil à retordre (j'utilise Git souvent).
Autre exemple, écrire un article en LaTeX. On travaille ensemble sur un peu tout, en s'échangeant parfois les parties à rédiger, à relire et à corriger. Parfois on fait des conneries, par exemple on résout mal un conflit. Ça peut arriver parce qu'on a choisi de travailler avec un co-auteur pour ses compétences en maths ou en littérature, pas parce qu'il maîtrise tel ou tel VCS. Il faut pouvoir virer le patch foireux, ou au moins en calculer l'inverse, même si ce patch résout un conflit ou "merge" des choses.
[^] # Re: Soit j'ai rien compris soit...
Posté par pmeunier . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 4.
Celui qui dit c'est celui qui y est ? Aucune de mes réponses aux commentaires ici n'a été de mauvaise foi, ou n'a utilisé des exemples caricaturaux. Par contre, le coup des dix développeurs qui touchent la même fonction, il faut avouer que ça n'apporte pas grand chose au débat, on est tous d'accord qu'aucun outil ne va faire de miracle.
Je pense que la dichotomie entre les deux cas que tu décris montre bien en quoi Git transforme ses utilisateurs :
Avec Git, tout ce qui n'est pas à une personne et une branche n'est pas trivial. En gros, dès qu'il y a un merge sur le même fichier (même si les deux branches ont touché des morceaux très éloignés du fichier), il peut se passer n'importe quoi.
Là, on n'est carrément pas d'accord. Bien sûr, n'importe quoi de non-trivial sous Git demande de passer des heures à satisfaire les contraintes techniques de l'outil, de revoir la communication, de mieux former les collaborateurs du projet aux bonnes pratiques, de rendre le workflow plus rigoureux...
Parfois c'est aussi le cas dans d'autres systèmes de contrôle de version, bien sûr. Sauf que quand on travaille ensemble, la plupart des cas ne tombent dans aucune de tes deux catégories.
Dans mon expérience de programmeur et de co-auteur de textes en général, il y a plein de petits cas assez simples, mais pas complètement triviaux non plus. Bien sûr, on peut passer du temps à rebaser, à corriger les merges qui ont mélangé les lignes, à organiser ses branches en workflows. Mais avec un outil plus rigoureux, on pourrait aussi utiliser tout ce temps-là pour travailler sur le projet au lieu de satisfaire Git.
Exemple, dans l'écriture d'un projet comme Pijul, où les co-auteurs se font confiance et travaillent assez indépendamment sans se synchroniser outre mesure, il arrive qu'on ait des problèmes. Pourtant, vu qu'on travaille tous sur plein de sous-projets à la fois (parce qu'il y a beaucoup à faire, et qu'on n'est pas beaucoup), aucun de nous n'a envie d'adopter une structure rigide de branches, des merges temporaires pour vérifier que deux features passent bien ensemble, etc.
Un truc particulièrement difficile dans Pijul est que si on change la sortie d'un algo, il faut adapter tous les algos qui dépendait de cette sortie. Ça fait des gros patchs, mais avec Pijul on s'en sort très bien, je suis certain que Git nous aurait déjà donné du fil à retordre (j'utilise Git souvent).
Autre exemple, écrire un article en LaTeX. On travaille ensemble sur un peu tout, en s'échangeant parfois les parties à rédiger, à relire et à corriger. Parfois on fait des conneries, par exemple on résout mal un conflit. Ça peut arriver parce qu'on a choisi de travailler avec un co-auteur pour ses compétences en maths ou en littérature, pas parce qu'il maîtrise tel ou tel VCS. Il faut pouvoir virer le patch foireux, ou au moins en calculer l'inverse, même si ce patch résout un conflit ou "merge" des choses.