Personne n'a pensé que SVN aurait des concurrents sérieux...
Perforce avait une bonne part des parts de marché. Google est parti sur perforce tout au début et il y a en ce moment une migration lente sur les dépots internes vers git ( en ne faisant que des dépots git pour les nouveaux projets ), Perl a longtemps continué à utilisé perforce, freebsd aussi. Svn avait des concurrents sérieux depuis le début. Et bitkeeper est plus vieux que subversion de quelques mois, donc même le concept de Subversion n'était pas le plus novateur à l'époque. Avant git/hg, tu as eu tla, dont l'idée était séduisante, mais l’implémentation catastrophique.
Git est arrivé et n'a pas apparemment de plus pour une entreprise.
Sauf que Kernel.org a décidé de s'en servir...
Cette pub involontaire a permis à git de se faire connaître.
Git a des avantages pour une entreprise.
D'une part, git a des avantages vis à vis de svn sur le point de vue techniques. Il est plus rapide, permet de faire des git bisect efficaces, ce qui permet de chercher des bugs de façon plus rapide.
Ensuite, le fait que tout clone d'un dépôt git soit un clone complet permet de régler des souis d'ordre opérationnel, comme le fait d'avoir une liaison lente dans certains pays vis à vis de l'Europe. Exemple, le brésil, l'australie ont des liens internets limités. Et si donc tu as des bureaux la bas, pouvoir faire un miroir complet sans magouille est un avantage. ( ie, miroir en lecture ecriture ).
Ensuite, non, une entreprise qui développe a autant besoin de pouvoir faire des branches qu'un groupe comme kernel.org. Si tu fait un site de ecommerce, tu as ta version en production, ta version en dev, etc, et tu fait passer les commits de façon fluides d'un depot à l'autre. Faire des merges sous svn, c'est pourri, avec git, ça passe correctement.
D'ailleurs, la preuve que git apporte des choses, c'est qu'il y a plein de boites qui utilisent git. C'est que Google lache perforce pour git.
Et ensuite, git a été écrit par Linus Torvalds car les outils existants n'étaient pas adaptés. Donc c'est pas "kernel.org a fait de la pub involontaire". C'était très volontaire, d'une part, et avant, Linus utilisait bitkeeper, qui n'a pas lui pris le monde d'assaut, prouvant bien que la pub de kernel.org n'est pas une condition suffisante, ou même nécessaire.
Donc oui, git s'est imposé par ses qualités, pas parce que Linus a décidé de l'écrire ou de le faire. Si un outil réponds aux besoins des gens, les gens l'utilisent. Git réponds à ce besoin, c'est utilisé. Systemd réponds, c'est utilisé. Mercurial réponds aussi et permet d’expérimenter autrement, des gens l'utilisent, pareil pour upstart.
[^] # Re: C'est plus facile de travailler salement...
Posté par Misc (site web personnel) . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 6.
Perforce avait une bonne part des parts de marché. Google est parti sur perforce tout au début et il y a en ce moment une migration lente sur les dépots internes vers git ( en ne faisant que des dépots git pour les nouveaux projets ), Perl a longtemps continué à utilisé perforce, freebsd aussi. Svn avait des concurrents sérieux depuis le début. Et bitkeeper est plus vieux que subversion de quelques mois, donc même le concept de Subversion n'était pas le plus novateur à l'époque. Avant git/hg, tu as eu tla, dont l'idée était séduisante, mais l’implémentation catastrophique.
Git a des avantages pour une entreprise.
D'une part, git a des avantages vis à vis de svn sur le point de vue techniques. Il est plus rapide, permet de faire des git bisect efficaces, ce qui permet de chercher des bugs de façon plus rapide.
Ensuite, le fait que tout clone d'un dépôt git soit un clone complet permet de régler des souis d'ordre opérationnel, comme le fait d'avoir une liaison lente dans certains pays vis à vis de l'Europe. Exemple, le brésil, l'australie ont des liens internets limités. Et si donc tu as des bureaux la bas, pouvoir faire un miroir complet sans magouille est un avantage. ( ie, miroir en lecture ecriture ).
Ensuite, non, une entreprise qui développe a autant besoin de pouvoir faire des branches qu'un groupe comme kernel.org. Si tu fait un site de ecommerce, tu as ta version en production, ta version en dev, etc, et tu fait passer les commits de façon fluides d'un depot à l'autre. Faire des merges sous svn, c'est pourri, avec git, ça passe correctement.
D'ailleurs, la preuve que git apporte des choses, c'est qu'il y a plein de boites qui utilisent git. C'est que Google lache perforce pour git.
Et ensuite, git a été écrit par Linus Torvalds car les outils existants n'étaient pas adaptés. Donc c'est pas "kernel.org a fait de la pub involontaire". C'était très volontaire, d'une part, et avant, Linus utilisait bitkeeper, qui n'a pas lui pris le monde d'assaut, prouvant bien que la pub de kernel.org n'est pas une condition suffisante, ou même nécessaire.
Donc oui, git s'est imposé par ses qualités, pas parce que Linus a décidé de l'écrire ou de le faire. Si un outil réponds aux besoins des gens, les gens l'utilisent. Git réponds à ce besoin, c'est utilisé. Systemd réponds, c'est utilisé. Mercurial réponds aussi et permet d’expérimenter autrement, des gens l'utilisent, pareil pour upstart.