Surtout, git est optimise pour les besoins de Linus. Le fait que CVS et subversions ne conviennent pas a Linus mais conviennent a des milliers de projets Open Source devraient deja donner un indice que git n'est pas pour tout le monde.
Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)
Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
[^] # Re: Bazaar
Posté par Philippe F (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 6.
Quelques points notables:
- git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte. CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
- git est concu pour avoir une notion de tracabilite tres profonde, sur l'integralite des sources et des changements d'un projet, le tout valide par une signature cryptographique (SHA). Il est possible en une seule operation de savoir si deux jeux de source git sont identiques ou differents.
- git est optimise pour la notion de partage et de melange d'arbres differents, qui correspondent au modele de developpement du noyau : beaucoup de developpeurs avec des branches partielles (sous-systemes, experimentales) font d'abord des modifs dans leur branche avant de faire remonter la modif vers le repository de Linus.
Bref, pas grand chose a voir avec les besoins classiques d'un SCM :
- versionnement des fichiers
- remonter dans le temps sur les versions passees
- notion de branche
- notion de marquage (tag)
Apres, on peut rajouter d'autres fonctionnalites :
- commit atomiques
- renommage
- utilisation en mode completement decentralise facon arch
- interface conviviale
- compacite du stockage
- facilite de deploiement
- portabilite
- nombre d'outils et frontend associes
- stabilite
- dispoinbilite d'un frontend sous windows
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS et autres.
Je sais que dans ma boite precendent, la convivialite etait un element fondamental. Si l'outil n'etait pas convivial, les developpeurs ne l'utilisaient pas et continuaient avec leurs zip sur un serveur partage. Chaque usage a ses criteres particuliers.
Pour Linus, c'est git.