Dans mon précédent journal,
j'ai clairement indiqué ma préférence sur les gestionnaires de versions
distribués (comme Git), par rapport aux
gestionnaires de versions centralisés (comme
Subversion). Je n'avais alors pas
justifié ma position, mais je souhaite maintenant le faire. C'est vrai ca,
pourquoi Git* m'importe ?
Un des arguments souvent rencontrés pour justifier l'intérêt de Git est la
vitesse des opérations. C'est vrai que c'est agréable de pouvoir commiter
instantanément. Pourtant, je travaille régulièrement avec svn, et ce manque de
rapidité n'est pas quelque chose qui me gêne beaucoup. Cet argument à lui seul
ne suffit pas à justifier le passage de svn à Git.
Les gestionnaires de versions distribués permettent, par définition, de
commiter depuis n'importe où (dans le train, le métro, l'avion, les toilettes,
etc.). Pourtant, ce genre d'utilisations reste assez marginal, et à l'exception
de quelques personnes, c'est une possibilité extrêmement peu utilisée.
On peut également reprocher certaines choses à svn (comme l'impossibilité
d'annuler un commit), mais ce sont des choix de design de subversion, et un
autre gestionnaire centralisé pourrait les corriger.
Pour ma part, je pense que le plus grand apport de git est son aspect
distribué, ce qui permet de mettre entre toutes les mains un gestionnaire de
versions avec ses avantages. Avec subversion, seules les personnes autorisées
peuvent accéder au dépôt et créer des branches pour faire des essais. De
l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche
expérimentale et continuer à suivre les développements fait sur le dépôt
officiel.
Prenons un exemple (fictif) : je suis un utilisateur régulier du logiciel XYZ,
j'en suis content, mais je n'arrive jamais à m'y retrouver dans l'écran des
options. Je décide donc d'essayer de refaire cet écran, mais comme je passe
beaucoup de temps sur la tribune, il va probablement me falloir plusieurs
semaines avant de pouvoir proposer un patch à l'auteur.
Premier cas : le logiciel XYZ est versionné avec subversion. Je fais donc un
checkout du trunk, et je commence à travailler dessus. Au bout de deux
semaines, je commence à avoir une version intéressante de cet écran, mais entre
temps, le développement a continué sur le trunk, et une nouvelle option est
apparue. Je décide de faire un svn up, mais malheureusement, l'inévitable se
produit : un conflit sur plusieurs fichiers. Ce n'est pas très grave, j'arrive
à les corriger, et je peux me remettre au travail. J'arrive enfin à un écran
des options qui me convient, et juste au moment où j'allais me décider à
envoyer mon patch à l'auteur, je me dis que j'essayerais bien d'intervertir 2
options. Je fais ce dernier changement, mais pas le temps de le tester, je pars
en vacances. A mon retour, je me rends compte qu'intervertir ces 2 options
était une mauvaise idée. Malheureusement, comme je n'ai pas pu commité mes
changements, je me retrouve à devoir me rappeler ce que j'avais fait avant de
partir pour pouvoir annuler ces changements. Enfin, je peux proposer mon patch
à l'auteur. Ouf.
Deuxième cas : je fais un svn export du même dépôt, puis je créé un dépôt svn
local pour gérer mes avancées. Je peux tranquillement travailler sur mon écran
d'options. Quand j'arrive à quelque chose de convaincant, je propose un patch à
l'auteur, qui le refuse, car celui-ci ne s'applique pas sur le trunk. J'essaye
alors de me synchroniser avec le dépôt officiel, mais entre les nombreux
conflits et le trunk qui n'arrête pas d'évoluer, je finis par abandonner :(
Maintenant, le même scénario avec Git se serait beaucoup mieux passé. J'aurais
profité de tous les avantages d'un code versionné. Par exemple, j'aurais pu
commiter régulièrement mes avancées, ce qui m'aurais permis de profiter de git
diff, git log, etc. Si, après récupéré les mises à jour du dépôt officiel, je
me serais rendu compte que résoudre les conflits est plus compliqué que prévu,
je peux retourner à la révision précédente et continuer à travailler dessus (en
laissant le travail de résolution des conflits pour quand j'aurais plus de
temps/volonté à y consacrer). Enfin, je n'aurais rencontré aucune difficulté à
annuler un des mes changements. Bref, j'aurais pu profité des avantages d'un
code versionné.
Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages
(faire régulièrement des tarballs de ses avancées), mais imaginer que vous
vouliez vous mettre à plusieurs pour proposer une nouvelle fonctionnalité
majeure pour votre logiciel préféré. Bien entendu, vous n'avez pas accès au
dépôt officiel, sinon ce serait trop simple ;)
Pour moi, la grande force des gestionnaires de versions distribués est là :
pouvoir créer une branche même sans accès au dépôt officiel. Cette branche
distante est la seule façon sereine de faire des développements expérimentaux
tout en continuant à se synchroniser sur la base de code officielle. Les
gestionnaires de versions distribués cassent cette barrière entre ceux qui ont
accès au dépot officiel et les autres.
* je parle de Git, mais Mercurial ou Bazaar-NG ou un autre DSCM ferait aussi l'affaire.
# Commentaire supprimé
Posté par Anonyme . Évalué à 9.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: git > bzr
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Est-ce que git est vraiment mieux à ce niveau ? Est-ce qu'il existe des interfaces permettant d'utiliser une interface git sur un serveur SVN ? Et le contraire ? Et y'a-t-il un document "Git pour les administrateurs SVN" qui me permettrait de convaincre mon admin SVN de tenter le coup de Git ? Et un document simple et clair à destinations des développeurs ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: git > bzr
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Et je ne pense pas que git soit plus à l'abri d'une interface graphique boguée.
[^] # Re: git > bzr
Posté par Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: git > bzr
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: git > bzr
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
grep toto -rn *
(enfin, sauf si on veut que grep regarde aussi dans des fichiers cachés dans le répertoire racine)
Avec subversion, le même va ignorer le .svn à la racine, mais pas les autres. Résultat, c'est beaucoup plus facile de foutre en l'air (là, j'ai pris grep, mais on peut faire pareil avec un « perl -pi -e ... » ...) une copie de travail svn qu'une copie de travail avec git. Par contre, les conséquences d'une corruption du .git/ sont en général plus désastreuses avec Git qu'avec SVN ...
[^] # Re: git > bzr
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
[^] # Re: git > bzr
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Ceci dit, y'a pas de solution parfaite : avec SVK, si tu déplaces ta copie de travail, ça met aussi le bronx. Mais l'argument est que ça arrive moins souvent de déplacer sa copie de travail que de faire des conneries avec les .bidules/ à l'intérieur de la copie de travail.
Au passage, avec Git, on peut simuler un comportement à la SVK en positionnant $GIT_DIR. Mais évidemment, si on a plusieurs repositories, c'est affreusement pas pratique de devoir changer la variable d'environnement à chaque fois qu'on change de copie de travail. C'est plus un truc pour cas particuliers dans des scripts que vraiment adapté à une utilisation quotidienne.
[^] # Re: git > bzr
Posté par Raphaël SurcouF (site web personnel) . Évalué à 1.
Je voulais m'en servir pour pouvoir déplacer ma copie sur clé usb mais je ne vois pas comment replacer la dite copie dans le giron du SVK local...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# Re:
Posté par IsNotGood . Évalué à 10.
On peut annuler un commit. Mais il faut savoir ce que tu entends par annuler. Ce qu'on peut faire avec svn, c'est ajouter une transaction qui annule la précédente. La précédente est toujours dans le dépôt mais n'est plus visible dans la version HEAD. Pour ce faire on "commit" l'inverse du commit qu'on veut annuler (ça demande qu'une ligne de commande).
Notons qu'il n'y a guêre le choix.
Tu soumets des modifications et avant que tu "annules" d'autres peuvent avoir fait un "svn update". Il y a le même problème avec git...
Tu peux "réellement" annuler une transaction si t'es admin. C'est possible, mais ce n'est pas recommandé.
> Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.
Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.
> De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
Tu peux aussi le faire avec svn.
> Maintenant, le même scénario avec Git se serait beaucoup mieux passé.
Je ne vois pas pourquoi. Si des fichiers sont en conflit, ben ils sont en conflit. Avec svn ou git, ils sont en conflit.
De plus tu n'es pas obligé de bosser sur la branche truck. Tu peux avoir une branche de développement que tu synchronises de temps à autres avec trunk (tu merges ce qui est fait dans trunk). C'est très commun comme usage de svn. Lorsque tu es content de ta version tu envois le diff entre ta blanche de développement et trunk. Ta branche de développement peut être un dépôt subversion local ou être sur le serveur principal.
Mes dépôts subversions n'ont pas de développement direct dans /trunk. Tout est fait dans /devel. Lorsqu'une modification est satisfaisante, elle est fusionnée dans trunk. C'est un modèle qui a ses avantages et inconvénients. Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).
> Enfin, je n'aurais rencontré aucune difficulté à annuler un des mes changements.
Il n'y a aucune difficulté à annuler des changements avec svn.
> Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages
On peut le faire sans bidouillage.
> Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.
Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).
> Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.
Non, l'intérêt n'est pas là.
Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.
[^] # Re: Re:
Posté par Olivier Tétard (site web personnel) . Évalué à 4.
Sauf que pour publier ton dépot, c'est plus compliqué. Ensuite, lors de la fusion des patchs, tu perds de l'information (la branche d'origine, les différentes étapes qui ont amené à ce patch, ...).
>> Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.
>
> Non, l'intérêt n'est pas là.
Un peu quand même. Si tu veux faire une modification importante à un logiciel, il est important de séparer le travail effectué en différents patchs, et le plus simple est de pouvoir commiter ces derniers. Les DSCM permettent de le faire facilement. Tu publies tes patchs (ta branche) qui pourra être ensuite fusionnée avec la branche principale (ou pas).
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
Ouuaiifff.
> Ensuite, lors de la fusion des patchs, tu perds de l'information (la branche d'origine, les différentes étapes qui ont amené à ce patch, ...).
Oui mais bof.
> il est important de séparer le travail effectué en différents patchs, et le plus simple est de pouvoir commiter ces derniers. Les DSCM permettent de le faire facilement. Tu publies tes patchs (ta branche) qui pourra être ensuite fusionnée avec la branche principale (ou pas).
Cet argument est pertinant. Ceux de Bruno Michel ne le sont pas.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 3.
Plus précisément, ce n'est pas l'aspect décentralisé qui est important. Mais l'aspect patch set. On ne travail pas avec un état des sources, mais avec un ensemble de patchs.
Ça a des avantages (grosse souplesse, on peut plus facilement faire une branche qui est la fusion de plusieures parties d'autres branches) et des inconvénients (c'est plus le bordel).
[^] # svn + svk
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 3.
http://search.cpan.org/dist/SVK/
[^] # Re: svn + svk
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Je pose la question, car la dernière fois que je l'ai utilisé, j'ai eu plus de problèmes qu'autre chose (avec des messages d'erreur qui ne voulaient pas dire grand chose). Ca doit faire 2 ans, donc svk a largement pu évoluer depuis, et j'aimerais savoir si tu as un retour d'expérience à nous faire partager sur le sujet.
[^] # Re: svn + svk
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
SVK ajoute à SVN la décentralisation sans remettre en cause le dépôt initial.
Cependant, rien n'oblige à disposer d'un référentiel central : on peut travailler en local juste avec SVK : l'intérêt réside dans le fait que SVK ne stocke aucun de ses fichiers dans le répertoire de travail (et pour journaliser des fichiers de configuration ou des configurations de cfengine, c'est pas mal).
Pour un retour d'expérience, je t'invite à lire l'article[1] de Nicolas Chuche publié dans le numéro 94 de Linux Magazine (pour git, il y a eu récemment deux articles dans les n°101 et 103).
Par rapport à git ou bazaar, le seul cas que ces derniers pourraient éventuellement apporter quelque chose, c'est dans le cadre d'un poste de travail complètement isolé de l'Internet, et donc d'une quelconque liaison directe avec un éventuel référentiel (à moins de passer par une clé usb).
Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.
[1]: http://articles.mongueurs.net/magazines/linuxmag94.html
[^] # Re: svn + svk
Posté par gst . Évalué à 2.
... mwouiii.
bon d'accord : on *pourrait* dire que la renomée de Linus aurait influencé sur la bonne prise en main de Git par tout un chacun mais je doute que ça soit suffisant... sinon pourportnawakilapluka..
bon je suis un convaincu : git me permet, facilement, tout ce que je souhaite ; la finesse en même temps que l' "exactitude" et la performance.. que demande le peuple..
bon après pour les arguments : bah voire les sources :p
[^] # Re: svn + svk
Posté par CrEv (site web personnel) . Évalué à 3.
pour ma part j'ai au contraire une bien mauvaise expérience de svk...
J'ai voulu l'utiliser dans mon travail pour justement pouvoir bosser sur une branche "locale" pour ne commiter réellement que du code correct (mon code ne s'inscrivait pas dans le tron et pas envie de créer une branche sur le serveur pour ça, mais pas envie de ne pas commiter pour autant -> besoin de version décentralisée)
Les commits (et updates, mais surtout commit dans mon souvenir) sont très lents
Et j'ai eu de nombreux problèmes lors des synchros avec le trunk principal, des fichiers mal mergés, ...
Je crois que c'est la dernière fois que j'utilise svk, et je pense que je vais me tourner vers git-svn pour voir ce que ça donne
Je pense que git n'est pas populaire parce que c'est celui de Linus (qui d'ailleurs ne le maintient plus) Evidemment le fait qu'il l'ai initié a forcément joué mais il a aussi été très décrié à sa sortie.
Et on parle / parlais aussi avant de mercurial, bzr, monotone, ...
Mais ce dont je me rend compte c'est plutôt que beaucoup de personnes se sont mis à l'améliorer et est donc très vite venu au niveau des autres bon gestionnaires décentralisés, ceci justement parce qu'il est utilisé à la base pour le noyau. Mais on se rend compte qu'il est désormais utilisé pour des projets de taille beaucoup plus faible et je pense pas que ce soit uniquement pour les beau yeux de Linus...
[^] # Re: svn + svk
Posté par Erwan . Évalué à 3.
OK, c'est peut-etre pour ca que beaucoup essayent git... Mais c'est pour ses qualites intrinseques qu'on y reste (et qu'on va jusqu'a l'utiliser sur des depots SVN).
[^] # Re: svn + svk
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 10.
Sauf à être admin, on ne peut pas annuler un commit avec svn. Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité. Par contre, git permet de réellement annuler un commit (souvent pour le refaire plus proprement juste derrière).
> Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.
Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.
C'est bien ce que je dis : seuls les gens autorisés peuvent le faire. Éventuellement, l'admin peut autoriser tout le monde mais, en pratique, très peu de projets libres ont un svn ou tout le monde peut commiter.
> De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
Tu peux aussi le faire avec svn.
Si je n'ai qu'un accès en lecture seule sur le dépôt, je ne vois pas comment faire ca.
Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).
J'ai lu la doc de subversion, je pense savoir de quoi je parle, et je n'ai vu nulle part comment faire une branche distante et la garder à jour. Maintenant, si tu as un lien qui dis le contraire, postes-le.
> Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.
Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).
Justement, avec Git, ce n'est pas à la main, et c'est ce qui fait toute la différence : git pull est là pour ca.
Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.
J'utilise quotidiennement svn au boulot, et ce depuis plusieurs années. En plus, je le trouve tout à fait adapté à cette utilisation. Par contre, pour les logiciels libres (notamment tous ceux hébergés sur sourceforge, gna, savannah, etc.), j'espère que Git va devenir plus populaire, car il permet vraiment de nouvelles manières de développer.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Oui. Mais c'est du détail. Et ça relève aussi de la "politique". Est-il normal de supprimer un commit d'un gestionnaire de version public ? Pas évident de répondre à ça. Pour ma part je pense que non. C'est comme supprimer un commentaire ou un journal sur dlfp. Que l'admin puisse le faire est normal. Que l'utilisateur puisse le faire est plus discutable et d'autant plus pour un gestionnaire un version.
> C'est bien ce que je dis : seuls les gens autorisés peuvent le faire.
Et pour ton dépôt git ?
Tout le monde peut écrire dedans ?
Et es-ce parce que tu vas avoir ton propre dépôt que ça va être mergé en upstream ?
J'en doute.
La majorité des admins te donne un espace sur leur serveur svn si tu en as besoin.
Il faut aussi prendre en compte les effets sur la communication. Si toutes les branches sont sur le même serveur, et bien tout le monde peut voir le travail des autres, et merger, et le proposer en upstream, etc.
Si chaqu'un fait ça dans son coin...
> Si je n'ai qu'un accès en lecture seule sur le dépôt, je ne vois pas comment faire ca.
Ça se fait aussi avec svn. Après si tu ne veux pas le faire, ben ne le fait pas.
Es-ce que c'est plus pratique de le faire git ? Probablement.
> J'ai lu la doc de subversion, je pense savoir de quoi je parle, et je n'ai vu nulle part comment faire une branche distante et la garder à jour.
C'est vrai que ça ne saute pas yeux. Mais l'idée est là :
http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr(...)
Si en plus ce avec quoi tu dois te synchroniser est un dépôt svn, c'est encore plus simple.
J'image que tu vas dire que c'est un enfer, etc mais ça se fait très bien si tu n'as pas deux mains gauches et un cerveau de poulpe.
> J'utilise quotidiennement svn au boulot, et ce depuis plusieurs années.
Désolé, mais parfois on ne dirait pas.
> j'espère que Git va devenir plus populaire, car il permet vraiment de nouvelles manières de développer.
Pour développer dans son coin c'est très bien.
Mais in fine, pour la majorité des projets, es-ce bien pour le projet ? J'en suis moins sûr.
C'est clair que git ou des choses comme ça ont leur place pour les projets hors-norme. Par exemple Linux. Le dernier patch de 2.6.23 à 2.6.24 :
10209 files changed, 776107 insertions(+), 483031 deletions(-)
Tu travailles souvent sur des projets de ce type ?
Moi pas.
En jours ouvré ça fait 1000 lignes d'ajouté par jour !
[^] # Re: Re:
Posté par Marc Maurice (site web personnel) . Évalué à 7.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Il ne sait pas de quoi il parle, mais il adore venir troller sur les journaux qui en parlent.
[^] # Re: Re:
Posté par imalip . Évalué à 3.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 3.
http://blog.menfin.info/post/2007/09/23/SEPT-RAISONS-POUR-LE(...)
[^] # Re: Re:
Posté par paul . Évalué à 8.
Si jamais t'écris un jour un logiciel et que tu veux avoir un retour d'un non-utilisateur, demande à IsNotGood, c'est le seul à assurer ce service en permanence et cela pour tout logiciel. Basé sur la technologie ZOB (Zoning-On-Blogosphere), ce à quoi il s'adonne vraisemblablement toute la journée, il pourra te faire un compte rendu intégral des contresens et idées reçues qui pullulent autour de ton logiciel. En plus c'est gratuit, profites-en.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Merci pour le lien. Je ne connaissais pas. Je pense que j'avais sauté cette section en me disant que vendor, c'est juste pour suivre ce qui vient de l'extérieur (svn ou autre), mais sans le modifier.
> C'est clair que git ou des choses comme ça ont leur place pour les projets hors-norme.
Justement, je pense que git a aussi sa place pour les projets moins importants. Il favorise les développements en parallèle en simplifiant le suivi et la réunification de branches.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Le premier exemple est les bundles pour TextMate :
« Whilst Git was created by Linus for managing the Linux project, I get the feeling that Git’s raison d’être was to manage TextMate bundles. Weird since Linus probably doesn’t use TextMate.
A TextMate bundle is a combination of common/default snippets and personal snippets. Those personal snippets may even be useful for other people. Other people way want them. They may even join the set of default snippets. »
Source : http://drnicwilliams.com/2008/02/03/using-git-within-a-team/
En effet, les bundles de TextMate (ou les extensions d'emacs ou les fichiers de syntaxe de vim, etc.) sont des fichiers que l'on partage, mais qui sont souvent légèrement modifiés : changer le raccourci clavier pour telle fonctionnalité car il est dur à taper sur un clavier azerty, remplacer une couleur par une autre, désactiver telle option parce que l'on a un plugin qui fait ca en mieux...
Le deuxième exemple est les plugins pour Ruby on Rails.
« Also, I believe that a lot of developers will also be motivated to move their plugins/gems to GitHub because they simply can't always maintain their own libs and/or just hope people will fork their project and contribute back. »
Source : http://railsontherun.com/2008/3/5/starting-the-migration-to-(...)
« This marks a turning point for me in my opensource contribution. The barrier to entry for pushing patches is so low that I expect to see myself cloning a bunch more repos and making my teeny tiny fixes. »
Source : http://blog.bitfluent.com/post/26592090
Quand on utilise régulièrement les plugins pour Ruby on Rails, on
se retrouve souvent à devoir faire des modifications sur les plugins : traduire les messages d'erreur, remplacer une bibliothèque par une autre (rmagick -> mini-magick), adapter le plugin pour qu'il passe avec la dernière version de rails... La plupart de ces modifications n'arriveront jamais sur le dépôt officiel, et l'on se retrouve à refaire les mêmes changements à chaque mise à jour d'un plugin, car c'est plus rapide de refaire les changements que d'essayer de merger les changements avec svn. De l'autre coté, avec git et github, on est encouragé à faire des branches séparées et les partager.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Tout dépend où on met la barre. Il y aura forcément du flou. Puis si les utilisateurs sont habitués à git, ben autant utiliser git même s'il n'est pas "nécessaires".
[^] # Re: Re:
Posté par Sébastien Le Ray . Évalué à 0.
Par exemple, si je me suis trompé dans mon message de commit, je ne pourrais le changer, même si je m'en rends compte 2 secondes après avoir commité.
C'est juste faux, il suffit d'avoir le hook qui va bien.
Après c'est un choix de l'admin du serveur... Mais après tout c'est comme tout ce qui est collaboratif, ce sont les admins qui décident... Je trouve ça plus sain qu'un truc ouvert où on peut faire ce qu'on veut et où l'admin doit fermer des possibilités.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Mon exemple est le suivant : on m'envoie un patch par mail, je l'applique en local, le teste, et ca semble bien marcher. Je le commite donc dans le dépôt officiel. Dans mon message de commit, je remercie l'auteur du patch. Juste après, je retourne dans client mail, et là, je me rends que j'ai mal orthographié le prénom de l'auteur du patch.
Sous git, je peux annuler ce commit, et le refaire avec le prénom correctement orthographié. Sous svn, quel hook me permettrait de faire ca ?
[^] # Re: Re:
Posté par Sébastien Le Ray . Évalué à 10.
On s'est donc bien compris, il suffit effectivement d'un hook pour autoriser de telles modifications.
Ensuite pour l'annulation d'un commit, un simple svn merge -r revAAnnuler-1:revAAnnuler suffit. Ca ne supprime pas la révision annulée du référentiel, cela en crée une nouvelle qui annule la précédente, ce qui me semble être correct pour un gestionnaire de version (on ne perd rien...)
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 2.
OK, merci pour l'info. Je n'avais jamais entendu parlé de cette possibilité.
> Ensuite pour l'annulation d'un commit, un simple svn merge -r revAAnnuler-1:revAAnnuler suffit.
svn merge -r revAAnnuler:revAAnnuler-1 d'ailleurs.
[^] # Re: Re:
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par Erwan . Évalué à 4.
D'ailleurs, avec GIT il aurait meme pas eu a refaire son commit, parce qu'il n'aurait pas pu faire de faute d'orthographe: il aurait fait un pull depuis le repository du contributeur et le commit aurait apparu directement comme etait fait par le contributeur en question :)
[^] # Re: Re:
Posté par Guillaume Knispel . Évalué à 4.
Si le but est de ne pas perdre de temps ni se faire des noeuds dans le cerveau pour arriver à ses fins, alors je conçois sans problème que pour faire du développement décentralisé un gestionnaire de version décentralisé soit plus adapté qu'un gestionnaire de version centralisé :)
# Utilisez git-svn
Posté par Alban Crequy (site web personnel) . Évalué à 9.
Ca permet de faire des commits locaux, des branches de tests, des synchronisations avec d'autres développeurs (les avantages d'un vrai repository git), tout en laissant le choix aux autres de continuer à utiliser SVN.
On peut faire apparaître les branches SVN dans git. On peut aussi se récupérer les dernières versions SVN (git-svn fetch), commiter sur le SVN si on en a les droits (git-svn dcommit).
Exemple:
$ git-branch -a
master
* feature1
developer1/master
developer1/feature1
developer1/feature2
git-svn
mypublicrepos/master
mypublicrepos/feature1
Pour initier le repository git local, on peut soit prendre toutes les révisions SVN (ce qui prend du temps à télécharger!), soit juste prendre la dernière révision, et travailler à partir de là.
Bref, on peut avoir tous les avantages de git même si le projet utilise SVN.
[^] # Re: Utilisez git-svn
Posté par enzbang (site web personnel) . Évalué à 1.
On est limité à un modèle bien défini pour soumettre ses modifications. git-svn dcommit ne permet par exemple que de "rebaser" ses derniers commits.
J'utilise git-svn tous les jours et j'en suis vraiment très content. Il y a eu de très gros progrès récemment. Mais je préfère de loin une utilisation tout git.
[^] # Re: Utilisez git-svn
Posté par Alban Crequy (site web personnel) . Évalué à 1.
(Cette question n'a rien à voir avec git-svn)
[^] # Re: Utilisez git-svn
Posté par Misc (site web personnel) . Évalué à 1.
[^] # Re: Utilisez git-svn
Posté par Alban Crequy (site web personnel) . Évalué à 2.
# Vidéo
Posté par patrick_g (site web personnel) . Évalué à 10.
http://video.google.fr/videoplay?docid=-2199332044603874737&(...)
Comme souvent avec Linus c'est drôle et en plus on comprend mieux es avantages de Git.
[^] # Re: Vidéo
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Vidéo
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Et j'adore un des commentaires de cette vidéo : He's the Dr. House of Software Architects :)
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Vidéo
Posté par GPL . Évalué à 1.
Est-ce qu'une bonne âme peut récupérer le .flv et le mettre sur un service comme dl.free.fr
merciiiiiiiiiiiiiiiiiii!
[^] # Re: Vidéo
Posté par Mjules (site web personnel) . Évalué à 1.
sinon, tu peux utiliser des services en ligne comme http://keepvid.com/
ou encore les scripts du type youtube-dl ( http://www.arrakis.es/~rggi3/youtube-dl/ , il y en a pour presques tous les sites)
[^] # Re: Vidéo
Posté par GPL . Évalué à 3.
Je me suis mis à GIT depuis que je me suis mis dans la tête de bosser sur la nouvelle pile graphique pour linux.
J'avoue que je retouve fidèlement tous les avantages dont il parle. D'ailleurs maintenant, j'ai du mal à supporter les contraintes d'un système centralisé (CVS/SVN me donnent des boutons).
Bref... j'invité vraiment les projets open source à passer sous GIT. En plus c'est du C sous GPL donc du vraiment bon.
# les perfs
Posté par Erwan . Évalué à 3.
Flock par exemple est sur SVN, et c'est gros parce qu'on a tout le code source de Firefox dedans (avec les metadonnees CVS en plus). Pour ma part (et avec d'autres collegues) j'utilise GIT, et:
1) c'est bien plus rapide.
2) ca ne met pas ma machine a genoux quand je fait un update
3) ca prends moins de place sur le disque - alors que j'ai tout l'historique en local!
[^] # Re: les perfs
Posté par IsNotGood . Évalué à -6.
Il reste des Z80 ?
# Comparatif ?
Posté par Natja . Évalué à 1.
Quelqu'un aurait-il des pistes sur ce sujet ?
# mettre un tag
Posté par goeb . Évalué à 1.
Est-ce possible avec git ?
Exemple :
fichier1 : r100 (numero de version SVN)
fichier2 : r99
fichier3 : r103
fichier4 : r100
fichier5 : r101
Avec CVS on peut tagguer fichiers 1, 2, 3, (uniquement ces 3) avec TAG_V1 par exemple. et faire plus tard des update, checkout et diff par rapport à cette version TAG_V1.
Mais avec SVN ce n'est pas possible.
C'est très utile quand 2 développeurs travaillent en parallèle, et que certaines modifs de l'un doivent être livrées, alors que d'autres modifs de l'autre developpeur ne seront pas livrées tout de suite.
[^] # Re: mettre un tag
Posté par Amand Tihon (site web personnel) . Évalué à 3.
Dans un cas comme celui-ci, tu vas simplement créer une nouvelle branche (appelons-la V1) et y merger ce qui t'intéresse. Et comme de toute façon, chacun des deux développeurs travaille dans sa branche, ce sera très facile à faire.
[^] # Re: mettre un tag
Posté par Zenitram (site web personnel) . Évalué à 7.
Le gros problème de CVS est justement cette gestion par fichier : un tag peut alors être très incohérent, car le tag n'est pas précis dans le temps pour l'ensemble du logiciel.
Je suis passé il y a peu de CVS à SVN, ça m'a gonflé pas mal au début cette gestion des tags par la création obligatoire d'une branche pour le soft en entier, et puis... Après réflexion, c'est génial : c'est bien le soft en entier qu'on versionne, pas un fichier!
Dans ton exemple, TAG_V1 ne correspondrait pas un une V1 vraiment pendant que ton collègue n'a pas encore fait son patch. Ca serait inconsistant, une personne faisant un checkout sur ton soft en entier avec un filtre sur le Tag TAG_V1(qu'il verrait dans son gestionnaire, donc il se dira "super, la V1 est tagguée!) penserait avoir une V1, mais... Il lui manquera des fichiers, et ça ne compilera pas. Pas bon du tout.
# toilettes
Posté par Gof (site web personnel) . Évalué à 4.
> depuis n'importe où (dans le train, le métro, l'avion, les toilettes, etc.).
Comment !? Tu n'as pas enore internet dans ta toilette ?
Ah bhe oui, alors dans ce cas, Git c'est mieux :-)
# la Comtesse, à l'aide !
Posté par syntaxerror . Évalué à 4.
[^] # Re: la Comtesse, à l'aide !
Posté par meuble2001 . Évalué à 3.
# Multiple repositories
Posté par glisse . Évalué à 1.
- Pouvoir facilement recuperer du code de differents repository du meme projet (je fais ca tout le temps):
git-clone git://anongit.fdo.org/git/mesa
cd mesa
git-remote add toto git://toto.org/git/mesa
Et hop on peut recuperer les branches de toto faire du cherry picking et compagnies. A si vous connaissez titi ben vous pourrez aussi faire la meme chose.
- Git bitsect très utile pour retrouver une régression.
Donc git c'est bien ;)
[^] # Re: Multiple repositories
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
[^] # Re: Multiple repositories
Posté par Alban Crequy (site web personnel) . Évalué à 1.
Je préfère avec le tiret, ça fait des pages de man moins longues pour chaque commande.
[^] # Re: Multiple repositories
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
Deprecation notices
-------------------
* From v1.6.0, git will by default install dashed form of commands
(e.g. "git-commit") outside of users' normal $PATH, and will install
only selected commands ("git" itself, and "gitk") in $PATH. This
implies:
- Using dashed forms of git commands (e.g. "git-commit") from the
command line has been informally deprecated since early 2006, but
now it officially is, and will be removed in the future. Use
dash-less forms (e.g. "git commit") instead.
- Using dashed forms from your scripts, without first prepending the
return value from "git --exec-path" to the scripts' PATH, has been
informally deprecated since early 2006, but now it officially is.
- Use of dashed forms with "PATH=$(git --exec-path):$PATH; export
PATH" early in your script is not deprecated with this change.
Users are strongly encouraged to adjust their habits and scripts now
to prepare for this change.
Les raisons pour ça, entre autres :
* Les git-bidule ne permettent pas les aliases. Par exemple, chez moi, « git st » fait « git status », mais pour que « git-st » le fasse aussi, Git ne peut pas.
* Les git-bidule ne permettent pas les options globales, genre « git --no-pager foo ».
# Comment faire du développement dans l'industrie avec SGVD ?
Posté par Jetto . Évalué à 1.
Ce qui me semble difficile à implémenter c'est un cycle de développement avec des branches/streams de développement, d'intégration, de test, de release et de maintenance.
En plus dans un environnement où à la fois Unix et Windows peut-être utilisé il n'est pas facile de choisir un outil qui convienne aux 2.
Avez vous des idées sur comment utilisé ces outils pour répondre à ces 2 contraintes ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.