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.
Grossière erreur de logique.
Ceci dit, par ailleurs, git n'a jamais prétendu être pour tout le monde. Il ne prétend pas non plus être pour Linus et/ou Linux uniquement.
git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte.
C'est faux. Git stocke une version compressée des fichier (compression zlib maximum).
CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
C'est faux. Git peut stocker les objets sous forme compactée, et dans ce cas il est assez efficace en termes de stockage et encore tout à fait performant. Par exemple, Linux 2.6.11 avec son historique prend 191 Mo sous forme classique (chaque fichier étant compressé) et 62 Mo sous forme compactée. À comparer avec les 250 Mo des sources décompressées.
- versionnement des fichiers
Que veux-tu dire précisément ? Bien sûr que Git permet de retrouver les anciennes versions d'un fichier, même si techniquement ce n'est pas immédiat. Je ne sais pas si une commande existe déjà, mais conceptuellement je vois bien comment le faire : il faut remonter la hiérarchie des commits (donnée par git-rev-list), voir dans chaque arbre associé au commit si le fichier de même nom a la même signature SHA1. Si ce n'est pas le cas, tu as trouvé une ancienne version du fichier.
- remonter dans le temps sur les versions passees
Un petit coup de git-checkout permet de récupérer ultra-rapidement l'arborescence des fichiers telle qu'elle était à n'importe quel commit donné.
- notion de branche
Bien sûr. Git, comme tu le reconnais toi-même, c'est le royaume de la branche.
- notion de marquage (tag)
Bien sûr. En fait, n'importe quel objet peut être tagué. En général ce sont des commits qui sont tagués (pour marquer une version, typiquement), mais un arbre ou un fichier peuvent également l'être.
- commit atomiques
Je crois bien. De toute façon, vu que chacun bosse dans sa copie locale...
- renommage
Un point faible de Git, je pense. Pas facile de suivre à rebours l'évolution d'un fichier qui a changé de nom et de contenu. Trivial par contre de suivre l'évolution d'un fichier qui a changé de nom mais pas de contenu (merci SHA1).
- utilisation en mode completement decentralise facon arch
Bien sûr. C'est un des points forts de Git.
- interface conviviale
Le coeur de Git n'est pas convivial, et n'a pas à l'être. C'est de la plomberie. Pour la porcelaine, j'ai pas encore trop testé, mais gitk (explorateur de l'historique d'un projet) déchire grave, et git-web (même genre version html) déchire grave aussi. Cf. http://www.kernel.org/git/(...)
- compacite du stockage
Déjà traité, Git n'a pas à rougir.
- facilite de deploiement
Git est très simple et très léger, et ne requiert rien de bien méchant.
- portabilite
Git ne fonctionne effectivement pas (encore ?) sous Windows. Dommage. Il marche sous beaucoup d'Unix, y compris les versions récentes de Mac OS X.
Le projet n'a pas encore six mois, c'est clair qu'il bouge encore beaucoup. Mais qu'attendre d'autre au bout de seulement six mois ?
- dispoinbilite d'un frontend sous windows
Ah ben non, pas encore.
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS
Aucun des programmes que tu cites ne répondent à tous tes critères. Donc, égalité avec Git ! :-) Par ailleurs, tu as oublié le critère de performance. Git déchire grave et vite à ce niveau, plus que ceux que tu cites je pense.
[^] # Re: Bazaar
Posté par Boa Treize (site web personnel) . En réponse à la dépêche Des nouvelles des gestionnaires de versions GNU Arch et Bazaar. Évalué à 2.
Grossière erreur de logique.
Ceci dit, par ailleurs, git n'a jamais prétendu être pour tout le monde. Il ne prétend pas non plus être pour Linus et/ou Linux uniquement.
git stocke les fichiers integralement. Si tu changes une ligne a fichier texte de 50000 lignes, git restocke le fichier texte.
C'est faux. Git stocke une version compressée des fichier (compression zlib maximum).
CVS et consorts stockent un diff. Donc en terme de stockage, git n'est pas efficace et ce n'est pas son but.
C'est faux. Git peut stocker les objets sous forme compactée, et dans ce cas il est assez efficace en termes de stockage et encore tout à fait performant. Par exemple, Linux 2.6.11 avec son historique prend 191 Mo sous forme classique (chaque fichier étant compressé) et 62 Mo sous forme compactée. À comparer avec les 250 Mo des sources décompressées.
- versionnement des fichiers
Que veux-tu dire précisément ? Bien sûr que Git permet de retrouver les anciennes versions d'un fichier, même si techniquement ce n'est pas immédiat. Je ne sais pas si une commande existe déjà, mais conceptuellement je vois bien comment le faire : il faut remonter la hiérarchie des commits (donnée par git-rev-list), voir dans chaque arbre associé au commit si le fichier de même nom a la même signature SHA1. Si ce n'est pas le cas, tu as trouvé une ancienne version du fichier.
- remonter dans le temps sur les versions passees
Un petit coup de git-checkout permet de récupérer ultra-rapidement l'arborescence des fichiers telle qu'elle était à n'importe quel commit donné.
- notion de branche
Bien sûr. Git, comme tu le reconnais toi-même, c'est le royaume de la branche.
- notion de marquage (tag)
Bien sûr. En fait, n'importe quel objet peut être tagué. En général ce sont des commits qui sont tagués (pour marquer une version, typiquement), mais un arbre ou un fichier peuvent également l'être.
- commit atomiques
Je crois bien. De toute façon, vu que chacun bosse dans sa copie locale...
- renommage
Un point faible de Git, je pense. Pas facile de suivre à rebours l'évolution d'un fichier qui a changé de nom et de contenu. Trivial par contre de suivre l'évolution d'un fichier qui a changé de nom mais pas de contenu (merci SHA1).
- utilisation en mode completement decentralise facon arch
Bien sûr. C'est un des points forts de Git.
- interface conviviale
Le coeur de Git n'est pas convivial, et n'a pas à l'être. C'est de la plomberie. Pour la porcelaine, j'ai pas encore trop testé, mais gitk (explorateur de l'historique d'un projet) déchire grave, et git-web (même genre version html) déchire grave aussi. Cf. http://www.kernel.org/git/(...)
- compacite du stockage
Déjà traité, Git n'a pas à rougir.
- facilite de deploiement
Git est très simple et très léger, et ne requiert rien de bien méchant.
- portabilite
Git ne fonctionne effectivement pas (encore ?) sous Windows. Dommage. Il marche sous beaucoup d'Unix, y compris les versions récentes de Mac OS X.
- nombre d'outils et frontend associes
Ça évolue très vite. Cf. http://git.or.cz/(...)
- stabilite
Le projet n'a pas encore six mois, c'est clair qu'il bouge encore beaucoup. Mais qu'attendre d'autre au bout de seulement six mois ?
- dispoinbilite d'un frontend sous windows
Ah ben non, pas encore.
qui font qu'on aboutit a CVS, Monotone, subversion, arch, tla, bazaar, bazaar-ng, Super CVS
Aucun des programmes que tu cites ne répondent à tous tes critères. Donc, égalité avec Git ! :-) Par ailleurs, tu as oublié le critère de performance. Git déchire grave et vite à ce niveau, plus que ceux que tu cites je pense.