[...] les patchs sont plus intuitifs que les commits [...]
Euh... pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif. Les trois sont intuitifs, quand on a déjà des références, ce qui ne doit pas être impossible, surtout pour un développeur. Ça ne signifie pas nécessairement que ces termes sont interchangeables mais que leur compréhension est assez aisée.
Sinon, je pense que cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités. Qu'on appelle ce "truc" un "patch", un "commit", un "snapshot", quelle importance? Ce que demande un développeur, AMHA, c'est que l'outil fonctionne, qu'il lui donne satisfaction et lui permette de faire ce qu'il désire sans se prendre le chou. Maintenant, que ce soit à travers des "patches", des "commits", des "snapshots", des "branches", des "rebase"... tout ça c'est juste du formalisme à se farcir. Pour tirer le meilleur parti d'un outil, il faut maîtriser son utilisation — oui, le vocabulaire en fait partie.
En ce qui concerne un outil de gestion de code source — je parle pour moi — tout ce qui m'intéresse, c'est, par exemple:
est-ce que je peux l'apprendre tout seul comme un grand et l'utiliser?
est-ce qu'il me sauvegarde mes modif's sans me prendre la tête?
est-ce qu'il me fournit un historique de ce que j'ai fait?
est-ce qu'il me permet de naviguer dans mes révisions?
est-ce qu'il me permet de défaire ce que j'ai fait?
est-ce qu'il me permet de regrouper des changements?
est-ce que je peux récupérer des modif's, individuelles ou groupées?
est-ce qu'il est disponible au moins sur Windows, Linux et Mac, que je puisse partager du code avec n'importe qui?
Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet. En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel et, si vraiment je suis bouché, je trouve sur StackOverflow. Ou ailleurs.
Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git. Et il y a beaucoup de cerises sur le git-eau...
A priori Pijul ne donne pas de motif suffisant à changer par rapport à Git. Je pense que c'est l'un des points abordés par Jean Parpaillon dans ses commentaires.
Ceci dit, c'est très bien que des outils comme ça naissent aussi. Après tout, c'est aussi un des [nombreux] aspects du logiciel libre. Avoir plus d'un point de vue, éclairé ou pas, que chacun puisse faire son choix, en toute liberté, c'est bien. Après, c'est la nature [humaine] qui décide ;-) ...
[^] # Re: Soit j'ai rien compris soit...
Posté par FantastIX . En réponse à la dépêche Pijul, contrôle de version et théorie des patchs, version 0.12. Évalué à 3.
Euh... pardon? Je ne comprends pas cette affirmation. C'est comme affirmer "un dessin est plus intuitif qu'un crayon". C'est du moins comme ça que je perçois cette phrase.
Un commit, c'est une transaction, exactement comme pour une base de données. Un snapshot, c'est comme pour une VM: un cliché, un instantané. Un patch, c'est un correctif. Les trois sont intuitifs, quand on a déjà des références, ce qui ne doit pas être impossible, surtout pour un développeur. Ça ne signifie pas nécessairement que ces termes sont interchangeables mais que leur compréhension est assez aisée.
Sinon, je pense que cette discussion focalise un peu trop sur le vocabulaire par rapport aux fonctionnalités. Qu'on appelle ce "truc" un "patch", un "commit", un "snapshot", quelle importance? Ce que demande un développeur, AMHA, c'est que l'outil fonctionne, qu'il lui donne satisfaction et lui permette de faire ce qu'il désire sans se prendre le chou. Maintenant, que ce soit à travers des "patches", des "commits", des "snapshots", des "branches", des "rebase"... tout ça c'est juste du formalisme à se farcir. Pour tirer le meilleur parti d'un outil, il faut maîtriser son utilisation — oui, le vocabulaire en fait partie.
En ce qui concerne un outil de gestion de code source — je parle pour moi — tout ce qui m'intéresse, c'est, par exemple:
Avec ça, si je ne connais pas la commande, je sais que je peux la trouver sur internet. En fait je me moque pas mal que la commande ne soit pas intuitive car je n'ai pas besoin de me souvenir de toutes les commandes disponibles. J'ai les pages du manuel et, si vraiment je suis bouché, je trouve sur StackOverflow. Ou ailleurs.
Perso, je n'ai rien vu (rien cherché non plus, j'avoue), jusqu'à présent, qui me détourne de Git. Et il y a beaucoup de cerises sur le git-eau...
A priori Pijul ne donne pas de motif suffisant à changer par rapport à Git. Je pense que c'est l'un des points abordés par Jean Parpaillon dans ses commentaires.
Ceci dit, c'est très bien que des outils comme ça naissent aussi. Après tout, c'est aussi un des [nombreux] aspects du logiciel libre. Avoir plus d'un point de vue, éclairé ou pas, que chacun puisse faire son choix, en toute liberté, c'est bien. Après, c'est la nature [humaine] qui décide ;-) ...