Merci pour ce retour, très intéressant pour un utilisateur occasionnel (et grand fan) de git comme moi.
La seconde partie, surtout, apporte des informations très intéressantes.
Par contre sur la première partie, j'ai peur de ne pas être tout à fait d'accord avec toi.
oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouve Franchement ce n'est pas vraiment étonnant.
Il est plus simple de dire "pourquoi tu commences avec SVN alors que tu peux avoir quelque chose de mille fois plus puissant et performant avec GIT ?" plutôt que "pourquoi tu veux utiliser GIT ? Utilise un truc qui fait moins de choses, parce que... heu parce que tu es habitué et parce que tout le monde a toujours fait comme ça" (argument de Windowsien quoi).
On a beau être vendredi, je ne trolle qu'à moitié.
Dans mon ancienne boite, où je militais activement (mais sans plus, je ne suis qu'administrateur système, pas développeur, c'est leur problème s'ils ne choisissent pas les bons outils) pour un passage de SVN à GIT, le lead dev m'a opposé un argument imparable : "Ouais, mais GIT, ce n'est pas très connu, je ne sais pas si on peu vraiment s'y fier, alors que SVN, ça a fait ses preuves sur des gros projets comme apache et ses millions de lignes de code". J'ai beaucoup rigolé, et je crois que je ne l'ai jamais dit pourquoi sa réflexion était ridicule.
Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCS Je ne comprends pas bien l'argumentation là.
Tu es en train de dire que l'utilisation d'un outil distribué va à l'encontre du partage ?
On pourrait dire la même chose de la plupart des licences libres, copyleft ou pas. N'importe qui peut récupérer la source en local et ne pas contribuer upstream. Heureusement qu'on a l'aGPL, dans ce cas.
Et puis je ne suis pas très à l'aise avec la thèse disant que les DVCS seraient "malsains" parce qu'ils offrent plus de liberté à l'utilisateur (dont, cette soit disant liberté d'être plus individualiste qu'avec SVN, ce dont je ne suis pas du tout convaincu).
Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert. Et qu'est ce qui empêche de faire la même chose avec svn (un checkout et travailler en local ensuite) ?
Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être. Non, la raison d'être, c'est de permettre de cloner un repo facilement. C'est la raison d'être du logiciel libre. Si c'est libre mais qu'en pratique on ne peut pas forker, à quoi sert la liberté ?
En pratique, ça permet des choses comme les sous systèmes dans linux : Linus ne pull que parmi les branches de personnes de confiance, eux même prennent leurs commits depuis des personnes à qui ils délèguent leur confiance. On a ainsi une cathédrale de confiance redoutablement efficace.
Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ? Je ne vois pas le rapport.
Combien de projets "imposent" SVN en ne fournissant pas de tarball ? Combien de projets versionnés par SVN proposent de taper deux lignes pour récupérer les sources et aucun autre moyen de le faire ?
En soi, ce n'est pas grave. Mais en entreprise, derrière certains firewalls fascistes, ça rend les choses très compliquées et c'est relativement frustrant.
Bref, sur ce point là, GIT ou SVN, même combat. Dans les deux cas, rien n'empêche de fournir un tarball des sources sur un serveur http.
Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste. Je pense que tes conclusions sont un peu hatives :)
(version édulcorée de "foutaises")
Bonne continuation avec git. Vivement ton prochain feedback.
# Re: Git malgré moi
Posté par j_kerviel . En réponse au journal Git malgré moi. Évalué à 7.
Merci pour ce retour, très intéressant pour un utilisateur occasionnel (et grand fan) de git comme moi.
La seconde partie, surtout, apporte des informations très intéressantes.
Par contre sur la première partie, j'ai peur de ne pas être tout à fait d'accord avec toi.
oui, les utilisateurs habituels de Subversion ayant tendance à être moins casse-couilles à ce sujet, je trouveFranchement ce n'est pas vraiment étonnant.Il est plus simple de dire "pourquoi tu commences avec SVN alors que tu peux avoir quelque chose de mille fois plus puissant et performant avec GIT ?" plutôt que "pourquoi tu veux utiliser GIT ? Utilise un truc qui fait moins de choses, parce que... heu parce que tu es habitué et parce que tout le monde a toujours fait comme ça" (argument de Windowsien quoi).
On a beau être vendredi, je ne trolle qu'à moitié.
Dans mon ancienne boite, où je militais activement (mais sans plus, je ne suis qu'administrateur système, pas développeur, c'est leur problème s'ils ne choisissent pas les bons outils) pour un passage de SVN à GIT, le lead dev m'a opposé un argument imparable : "Ouais, mais GIT, ce n'est pas très connu, je ne sais pas si on peu vraiment s'y fier, alors que SVN, ça a fait ses preuves sur des gros projets comme apache et ses millions de lignes de code". J'ai beaucoup rigolé, et je crois que je ne l'ai jamais dit pourquoi sa réflexion était ridicule.
Version courte : parce qu'un DVCS favorise le travail solitaire isolé alors que ce comportement est techniquement banni d'office pour les VCSJe ne comprends pas bien l'argumentation là.Tu es en train de dire que l'utilisation d'un outil distribué va à l'encontre du partage ?
On pourrait dire la même chose de la plupart des licences libres, copyleft ou pas. N'importe qui peut récupérer la source en local et ne pas contribuer upstream. Heureusement qu'on a l'aGPL, dans ce cas.
Et puis je ne suis pas très à l'aise avec la thèse disant que les DVCS seraient "malsains" parce qu'ils offrent plus de liberté à l'utilisateur (dont, cette soit disant liberté d'être plus individualiste qu'avec SVN, ce dont je ne suis pas du tout convaincu).
Pouvoir cloner un dépôt et ensuite travailler en local sans même en rendre compte au mainteneur est pour moi une manière de faire très peu en adéquation avec un développement ouvert.Et qu'est ce qui empêche de faire la même chose avec svn (un checkout et travailler en local ensuite) ?Et ce comportement tient à la nature décentralisée de l'outil, les DVCS fonctionne comme ça, on n'y peut absolument rien, c'est leur raison d'être.Non, la raison d'être, c'est de permettre de cloner un repo facilement. C'est la raison d'être du logiciel libre. Si c'est libre mais qu'en pratique on ne peut pas forker, à quoi sert la liberté ?En pratique, ça permet des choses comme les sous systèmes dans linux : Linus ne pull que parmi les branches de personnes de confiance, eux même prennent leurs commits depuis des personnes à qui ils délèguent leur confiance. On a ainsi une cathédrale de confiance redoutablement efficace.
Mais il suffit de voir la quantité de dépôt de petits projets qu'on peut trouver sur le web (les bidule.git posés sur un site web, voir ashd pour le dernier que j'ai croisé) : un développeur a fait son truc dans son coin, a publié son boulot sous forme d'un .git et l'abandonne au bon vouloir. Quelle différence avec un simple tarball sinon d'imposer le VCS ?Je ne vois pas le rapport.Combien de projets "imposent" SVN en ne fournissant pas de tarball ? Combien de projets versionnés par SVN proposent de taper deux lignes pour récupérer les sources et aucun autre moyen de le faire ?
En soi, ce n'est pas grave. Mais en entreprise, derrière certains firewalls fascistes, ça rend les choses très compliquées et c'est relativement frustrant.
Bref, sur ce point là, GIT ou SVN, même combat. Dans les deux cas, rien n'empêche de fournir un tarball des sources sur un serveur http.
Je pense que ça tient à la nature de l'outil utilisé qui favorise ce comportement individualiste.Je pense que tes conclusions sont un peu hatives :)(version édulcorée de "foutaises")
Bonne continuation avec git. Vivement ton prochain feedback.