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.
> Lire le journal (64 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #914288.
Cette page a été générée par Templeet en 0.1026s (dont 0.0105 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re:
> On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit)
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:
> 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...).
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:
> Sauf que pour publier ton dépot, c'est plus compliqué.
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:
> Cet argument est pertinant.
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
Plus précisément, si on veut faire des choses évoluées avec SVN, il est conseillé d'utiliser en plus SVK :
http://search.cpan.org/dist/SVK/
Th. Thomas.
[^]Re: svn + svk
Ca marche maintenant SVK ?
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
Ça marche même très très bien.
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
> Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.
... 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
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
Pour finir, si git n'était pas LE gestionnaire de sources de Linus, on n'en parlerait pas autant.
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
J'approuve l'usage de SVK mais j'aurais plutôt utilisé « décentralisé » que le terme évolué ». Je ne trouve pas que le modèle décentralisé soit une évolution par rapport au modèle centralisé mais qu'ils sont complémentaires et ne répondent pas aux mêmes besoins. SVK en est la parfaite illustration.
[^]Re: Re:
On peut annuler un commit.
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:
> 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).
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:
T'as déjà utilisé Git IsNotGood ??
[^]Re: Re:
Mouais. Mais par "obligation" et durant très peu de temps (l'upstream utilisait git). Je ne prétend pas être un utilisateur et encore moins un spécialiste.
[^]Re: Re:
Non, de toute évidence.
Il ne sait pas de quoi il parle, mais il adore venir troller sur les journaux qui en parlent.
[^]Re: Re:
s/sur les journaux qui en parlent//
"While a monkey can be a manager, it takes a human to be an engineer" Erik Zapletal
[^]Re: Re:
Je crois que l'auteur du journal n'est pas maladroit non plus dans ce domaine
http://blog.menfin.info/post/2007/09/23/SEPT-RAISONS-POUR-LE(...)
[^]Re: Re:
T'as déjà lu les messages de IsNotGood, Marc ? :)
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.
paul
[^]Re: Re:
> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr(...)
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:
Voici deux exemples de projets de petite taille pour lesquels git est particulièrement bénéfique.
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:
> 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.
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:
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:
Je ne suis pas sûr que l'on se soit bien compris.
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:
http://subversion.tigris.org/faq.html#change-log-msg
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:
> http://subversion.tigris.org/faq.html#change-log-msg
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:
Pourquoi ne pas _simplement_ corriger la faute de frappe dans un nouveau commit ?
[^]Re: Re:
Parce qu'il s'agit du *message de commit*, pas d'un fichier.
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:
Évidemment qu'on peut faire des choses "exotiques" avec svn, moyennant une grande maîtrise de l'outil et de moultes configurations, mais sérieusement on ne peut pas prétendre que subversion soit ultimement adapté (et conçu pour !) les use cases que l'autre du journal présente.
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é :)