Forum général.général SubVersion vs Mercurial vs Git ...

Posté par phoenix (site web personnel) le 26 juillet 2011 à 14:03.

Étiquettes :

juil.

2011

Bonjour,

Je travail actuellement sur plusieurs projets libres sous SubVersion dont le seul contributeur est moi seul. Je commit de plusieurs PC différents (2 en général, parfois 3). Je me créé parfois des branches de développement (dans branches_dev), je possède également des branches (dans branches) pour chaque nouvelle version majeur, et j'utilise les tag (dans tags) pour chaque version mineurs.

Je m'intéresse un peu à Mercurial, mais la seul différence que je vois c'est la possession d'une copie complète de mon référentiel sur chaque poste (ce qui permet de faire des backups en cas de suhsi), la possibilité de faire des commit locaux (mais je ne suis pas sur d'en avoir l'utilité), et la possibilité de n'avoir pas besoin du réseau (là aussi j'ai généralement Internet à disposition).

Bref donc, la question que je me pose est :

Si je passe à Mercurial, est-ce uniquement de la branlette cérébrale, où puis-je y voir d'autres intérêts par rapport à SubVersion ?

Est-ce que Git est mieux que Mercurial (et si oui pourquoi ? et sachant que l'une des machines tournes sur un OS de malheur et qu'il me semble que Git n'y marche pas super bien).

Est-ce que vous connaissez un site à jour qui compare toutes les fonctionnalités des gestionnaire de version centralisé et décentralisé ?

Merci

# Mon point de vue, pour ce qu'il vaut... ;-)

Posté par ymorin le 26 juillet 2011 à 14:46. Évalué à 6.

Si je passe à Mercurial, est-ce uniquement de la branlette cérébrale, où puis-je y voir d'autres intérêts par rapport à SubVersion ?

Le "merge". Dans Subversion, j'ai toujours eu des embêtements de merge. Avec Mercurial, jamais. Des conflits, certes, mais pas d'embêtement. Par exemple, dans Subversion, les "tree conflicts", c'est une catastrophe à résoudre. Dans Mercurial, il n'y a même pas besoin de cette notion. Pareil pour git.

Est-ce que Git est mieux que Mercurial [...] ?

En venant de Subversion, Mercurial est plus évident que git, j'ai trouvé.

Certes, git c'est "le bien pasque c'est Linus qui l'a fait et qu'on utilise ça pour le noyau". git est puissant. Vraiment très puissant. Mais la gestion au quotidien est d'une complexité effrayante. Même si ça s'est amélioré au fil du temps, git reste vraiment un outil pour "power-user", alors que Mercurial est facile d'accès.

Après plus de deux ans de maintenance de mon projet avec Mercurial, je doit avouer que c'est vraiment puissant. Certes, je n'ai pas un modèle hyper-décentralisé comme le noyau, mais tout de même. Ce que j'apprécie énormément dans Mercurial, c'est la gestion intégrée des MQ, c-à-d une série de patchs dans laquelle on se balade par "push" et "pop", un peu à la quilt (qui a servi de référence pour les MQ).

Je participe aussi un peu à des projets sous git, et je dois avouer que heureusement stgit est là, sinon je ne sais pas comment les gens font pour faire des séries et naviguer facilement dedans.

De toute façon, il existe des moyens simples de passer de l'un à l'autre, si au final la solution que tu as choisie ne te plait pas.

Hop,
Moi.
- [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
  
  Posté par B16F4RV4RD1N le 26 juillet 2011 à 23:01. Évalué à 4.
  
  idem, mercurial c'est vraiment très bon.
  
  Par rapport à svn, ça ne m'a pas du tout compliqué la vie (je ne connais pas git en comparaison mais ça semble plus difficile à appréhender), juste quelques commandes en plus. L'utilisant pour un projet où je suis seul, je n'en tire sans doute pas toute la substantielle moelle, mais ça m'apporte plus que facilité que de désagrément, aussi il ne me viendrait plus à l'idée de retourner à svn.
  
  Pour comparer, par rapport à svn par exemple :
  
  les + :
  - décentralisé, si par exemple tu n'as pas accès à internet, tu peux continuer à commiter, pratique pour garder des traces de l'avancement du projet, ou éviter les conflits vu que ça encourage à commiter plus souvent
  - pas de fichiers .svn dans chaque sous-dossier (un seul .hg à la racine), c'est plus propre
  - possibiliter de commiter depuis n'importe quel sous-dossier, pas besoin d'être à la racine comme dans svn (ça reprendra en compte toute l'arborescence des modifications, comme ça on est sûr de ne rien oublier)
  - Un tutoriel vraiment sympa et drôle : http://hginit.com/ (en anglais), ça indique vraiment l'intérêt de passer à mercurial
  - possibilité avec la commande hg serve, d'activer un server mercurial (pas sécurisé !), sur http://localhost:8000/ avec graphs et possibilité de faire des pull et push dessus. Pratique pour visualiser les graphs rapidement (un peu comme dans google code), ou pour travailler en local (je répète, c'est pas sécurisé par défaut)
  - même un des concepteurs d'origine de svn est passé sur mercurial pour tous ses projets [cf. http://code.google.com/u/@UBdQRVJZDhBHXAh%2B/]
  
  le(s) - :
  quelques manipulations supplémentaires : push, pull et update mais ce n'est vraiment pas génant
  
  Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
  - [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
    
    Posté par Maxime (site web personnel) le 27 juillet 2011 à 13:39. Évalué à 3.
    pas de fichiers .svn dans chaque sous-dossier (un seul .hg à la racine), c'est plus propre
    Il me semblait avoir lu que ce n'était plus le cas depuis peu pour subversion. Mais je ne retrouve pas ma source. Je l'ai rêvé ou pas ?
    - [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
      
      Posté par Christophe HENRY (site web personnel) le 27 juillet 2011 à 13:57. Évalué à 0.
      La version que j'utilise :
      
      svn, version 1.6.17 (r1128011)
      
      Il y a toujours les .svn dans tous les répertoires et si on veut commiter l'ensemble de la copie de travail, il faut remonter tout en haut. Par contre, on peut commiter un seul sous-répertoire ou fichier.
      - [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
        
        Posté par Maxime (site web personnel) le 27 juillet 2011 à 14:36. Évalué à 2.
        
        Si effectivement cela a été corrigé, c'est probablement dans la version 1.7. Mais encore une fois, je n'en suis pas sûr.
        
        [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
        
        Posté par SamG le 27 juillet 2011 à 19:30. Évalué à 1.
        
        Effectivement c'est corrigé en version 1.7 qui est en version beta 2
        cf. http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
      - [^] # Re: Mon point de vue, pour ce qu'il vaut... ;-)
        
        Posté par wismerhill le 28 juillet 2011 à 19:05. Évalué à 2.
        
        Oui, ce sera dans subversion 1.7 (dès qu'il sortira), cf
        http://subversion.apache.org/docs/release-notes/1.7.html#wc-ng
        
        Enfin, moi je trouvais ça bien pratique que chaque sous-répertoire soit également une copie de travail valide, faudra que je change un peu mon mode de travail que je passera à subversion 1.7
# Mon utilisation de git ...

Posté par GaMa (site web personnel) le 26 juillet 2011 à 18:12. Évalué à 2.
Je travail moi aussi sur un petit projet dont je suis le seul contributeur.
Je code de chez moi, mais aussi un peu du boulot (pas du gros dev, mais comme je me sert du soft au boulot, j'ai souvent du bug fix à faire). De plus les sources sont publiées sur github.

J'ai plusieurs dépots:
- Un chez moi
- Un au boulot
- Un sur github
- Un sur une clé usb
J'apprécie énormément le coté décentralisé de git. Voici mon "workflow":
- Je développe principalement de chez moi.
- Je ne pousse sur le dépot public que à partir de chez moi.
- Le boulot me sert de cas d'utilisation réel, j'ai donc besoin de faire des échanges entre chez moi et le boulot sans passer par le dépot public, j'utilise donc ma clé usb.
- Les nouvelles features faites chez moi, sont pas obligatoirement bug clean.
- Je veux récupérer les bug fix que je fait au boulot chez moi.
- Les bug fix du boulot sont vite fait mal fait.
- J'ai des fois des changements du boulot que je ne veut pas pousser dans la branch principale.
- Avant de pousser sur le dépot public, je fait donc pas mal de nettoyage sur tous les commit fait un peu partout. Je réécrit donc un historique de commits propres qui décrivent bien les évolutions du code. Tous mes essais, retours en arrière et bugs dignes d'un dev de première année sont inconnus du dépot public.
Je pourrait faire à peut prêt équivalent avec svn : Avoir une branch dev sur svn, faire tous le dev dessus et pousser sans trop réflechir. Mais je perdrait pas mal de fonctionnalités comme :
- la possibilité de garder des dev privés
- pousser plusieurs commits sur le dépot publique tout en réécrivant l'historique des modif que j'ai faites.
- La simplicité d'avoir des dev temporaires/privés fait en cours de développement d'une feature, de les garder alors que je pousse la feature sur le dépot publique.
Je n'ai jamais utilisé Mercurial mais je pense qu'il doit être possible de faire à peut prêt la même chose qu'avec git. (Decentralized power)

Matthieu Gautier|irc:starmad
- [^] # Re: Mon utilisation de git ...
  
  Posté par wilk le 26 juillet 2011 à 19:12. Évalué à 2.
  
  Avant de pousser sur le dépot public, je fait donc pas mal de nettoyage sur tous les commit fait un peu partout. Je réécrit donc un historique de commits propres
  
  Tu fais comment exactement cette réécriture de l'historique ? J'aimerai comparer ça avec Mercurial.
  - [^] # Re: Mon utilisation de git ...
    
    Posté par GaMa (site web personnel) le 26 juillet 2011 à 20:19. Évalué à 4.
    Tous ce fait avec git rebase -i
    1. git tag toto
    2. git rebase -i origin/master (ça ouvre votre $EDITOR avec la liste des commits entre origin/master et la tête de branche)
      Je réordonne la liste des commits.
      
      J'indique si des commits doivent être mergé
      
      Je peut demander à git de s’arrêter en cour de rebase pour que je puisse éditer un commit (ou le couper en plusieurs parties)
    3. J'enregistre le fichier, je quitte l'éditeur.
    4. git fait tous le boulot.
    5. Si il y a des conflits suite à un réordonnancement, git s’arrête
    6. je résout le conflit.
      Si j'y arrive pas git rebase --abort et je me retrouve au point 2.
      
      Si j'y arrive git rebase --continue
    7. Si il faut je reprend au point 2
    8. Si ça part n'importe comment git reset --hard toto (et je repart au point 2)
    9. git push origin (pour pousser les commits sur le depot publique)
    10. git tag -d toto
    Pour résoudre les conflit un 'simple' git mergetool suffit
    
    Matthieu Gautier|irc:starmad
  - [^] # Re: Mon utilisation de git ...
    
    Posté par Krunch (site web personnel) le 26 juillet 2011 à 21:59. Évalué à 3.
    
    Comment tu fais avec Mercurial ?
    
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
    - [^] # Re: Mon utilisation de git ...
      
      Posté par ymorin le 26 juillet 2011 à 22:50. Évalué à 3.
      Comment tu fais avec Mercurial ?
      
      Avec Mercurial, il y a aussi l'action rebase, même si je ne l'utilise pas.
      
      J'ai plutôt tendance à utiliser des MQs, voire aussi à les versionner elle-mêmes.
      
      Qu'est-ce que les MQs ? C'est une série de patchs que tu peux empiler (qpush) et dépiler (qpop), les réordonner, le tout à volonté. Il y a d'autre possibilités, mais ceci est la base.
      
      Quand je travaille sur une fonctionnalité ou une correction de bug, je commence toujours une MQ. Par exemple, je décide d'ajouter une nouvelle fonction, et de l'utiliser un peu partout pour mutualiser le code :
      
      créer une MQ (automatiquement) et un premier patch
      hg qnew add-new-function
      
      ajouter de la nouvelle fonction
      
      créer un second patch
      hg qrefresh && hg qnew use-new-function
      
      modifier le code pour appeler la nouvelle fonction
      
      s'apercevoir que l'API a un manque
      
      dépiler au premier patch
      hg qrefresh && hg qpop
      
      changer la fonction
      
      empiler au patch suivant
      hg qrefresh && hg qpush
      
      modifier le code
      
      s'apercevoir d'un bug dans la fonction
      
      dépiler au premier patch
      hg qrefresh && hg qpop
      
      corriger la fonction
      
      empiler au patch suivant
      hg qrefresh && hg qpush
      
      tester, ça marche
      hg qfinish
      
      Et voilà. Et on peut aussi versionner les MQs, qui du coup se trouvent être un repository Mercurial à part entière, donc on peut le clonner, le pusher et le puller. Si je fais une MQ sur une machine A, et que je veux l'utiliser sur une machiune B , je peux, au choix :
      
      la cloner depuis la machine B via ssh vers la machine A
      
      la pusher depuis la machine A vers un repository en ligne, et ensuite la cloner sur la machine B
      
      clonner la MQ sur une clé USB sur la machine A, transférer la clé vers la machine B, et cloner la MQ depuis la clé USB sur la machine B
      
      J'utilise le plus souvent 1. et 2. Par exemple, pour le projet que je maintein et développe :
      
      Repository principal : http://crosstool-ng.org/hg/crosstool-ng/
      
      Repository MQ canadian : http://crosstool-ng.org/hg/crosstool-ng/ct-ng.canadian/
      
      Repository MQ complibs : http://crosstool-ng.org/hg/crosstool-ng/ct-ng.complibs/
      
      Pour utiliser ces deux MQs :
      $ hg clone http://crosstool-ng.org/hg/crosstool-ng/ $ cd crosstool-ng $ hg clone http://crosstool-ng.org/hg/crosstool-ng/ct-ng.canadian/ .hg/patches-canadian $ hg qq --create canadian $ hg clone http://crosstool-ng.org/hg/crosstool-ng/ct-ng.complibs .hg/patches-complibs $ hg qq --create complibs $ hg qq canadian complibs (active) patches
      
      (La MQ default est toujours créée.)
      
      Et après, je peux les pusher en retour vers le serveur:
      
      $ hg qq canadian $ hg qq canadian (active) complibs patches $ hg --mq push ssh://user@crostool-ng.org/hg/crosstool-ng/ct-ng.canadian/
      
      Maintenant, si le repository a changé, je dépile ma MQ, je pull les nouveaux changements, et je réapplique la MQ en résolvant les conflits :
      
      $ hg qpop --all $ hg pull --update $ hg qpush --all # Arrêt sur un conflit, résolution habituelle $ hg qrefresh $ hg qpush --all
      
      Ça fait aussi un espèce de rebase, si on veut. Alors oui, il y a certains petits manques par rapport à git. Par exemple, si un patch est déjà appliqué, qpush ne s'en aperçoit pas. C'est pas très grave, un qdelete fait l'affaire.
      
      Franchement, ce sont pour moi devenues des opérations triviales^Wbanales.
      
      J'utilise Mercurial pour gérer mon ${HOME}, pour gérer mes scripts de déploiement de machines virtuelles, etc...
      
      D'accord, peut-être que ça ne passe pas à l'échelle comme pour le noyau Linux, quoique de très gros projets sont gérés avec brio sous Mercurial.
      
      Hop,
      Moi.
    - [^] # Re: Mon utilisation de git ...
      
      Posté par wilk le 27 juillet 2011 à 10:02. Évalué à 1.
      
      A priori je ne cherche pas à réécrire l'historique... J'utilise rebase, pour rester synchro avec la branche principale sans avoir à faire des merges à tout bout de champ (hg pull --rebase va récupérer ce qui me manque de la branche principale et remettre mes patchs à la fin). Eventuellement j'utilise rebase --collapse pour regrouper mes patchs en un seul avant de tout renvoyer sur la principale.
      
      Je vois qu'il y a une extension histedit http://mercurial.selenic.com/wiki/HisteditExtension qui a l'air de se rapprocher du rebase git mais je ne l'ai jamais utilisée.
      - [^] # Re: Mon utilisation de git ...
        
        Posté par 🚲 Tanguy Ortolo (site web personnel) le 27 juillet 2011 à 12:33. Évalué à 1.
        
        J'utilise rebase, pour rester synchro avec la branche principale sans avoir à faire des merges à tout bout de champ
        
        À la place tu fais des rebase à tout bout de champ. Je ne vois pas trop l'intérêt.
        
        [^] # Re: Mon utilisation de git ...
        
        Posté par wilk le 27 juillet 2011 à 13:13. Évalué à 1.
        
        C'est dans le log final que ça change, au lieu d'avoir p1 p2 merge p3 p4 merge p5 p6 merge j'aurai p1 p2 p3 p4 p5 p6 merge
# L'inverse

Posté par wilk le 26 juillet 2011 à 18:26. Évalué à 5.

Et si tu te posais la question dans l'autre sens ? Que dirais-tu a quelqu'un qui se demande s'il doit passer de Mercurial à Subversion ? Surtout pour du dev seul ou il n'y a pas besoin de verrouiller un fichier. C'est de plus en plus difficile à comparer avec Subversion tant on commence à l'oublier... Pour ma part je suis passé directement de CVS à un DVCS (Mercurial maintenant). Pour résumer je dirai que c'est tellement plus simple (de l'installation à l'utilisation).

Les commits locaux deviendrons vite indispensables. Commit locaux ça peut vouloir dire sur la même machine dans un répertoire différent, pour tester une nouvelle fonctionnalité qui sera soit complètement abandonnée (rm du répertoire tout simplement), soit fusionnée sans soucis dès qu'elle est prête. Si le développement de cette fonctionnalité s'éternise elle restera facilement en phase avec la branche principale.

Il y a plein d'endroit où on peut trouver des arguments pour comparer le centralisé et le décentralisé, toutes les mailing-listes (et wiki) des projets libres qui ont fait le pas par ex. Mais c'est vrai qu'on met toujours en avant le travail en groupe. Personnellement, je travaille beaucoup seul et j'y trouve un intérêt aussi. Dès qu'on crée une branche c'est comme si on était 2 et ainsi de suite... J'suis une bande de développeur à moi tout seul je m'fend la gueule ;-) Et le jour ou un autre dev veut participer, tout est prêt, aucune configuration à faire, aucun risque... Pour improviser un petit sprint par ex, c'est un jeu d'enfant.
# Comparaison

Posté par pamputt le 27 juillet 2011 à 08:11. Évalué à 2.

Bonjour, au niveau de la comparaison entre plusieurs logiciels, tu peux toujours regarder Wikipédia : https://secure.wikimedia.org/wikipedia/en/wiki/Comparison_of_revision_control_software
# Git sur Windows

Posté par MyLordAngus le 27 juillet 2011 à 13:08. Évalué à 1.

sachant que l'une des machines tournes sur un OS de malheur et qu'il me semble que Git n'y marche pas super bien

Au boulot, je suis sur une machine Win XP. J'ai installé MsysGit et je n'ai pas rencontré le moindre soucis. Git sous Windows, par le passé ça pouvait être compliqué à mettre en place, mais actuellement, sans être aussi simple que sous Linux, c'est désormais facile à mettre en place. Juste faire attention à bien configurer ton éditeur/IDE pour qu'il utilise les fins de ligne Unix (\n), tu t'éviteras pas mal d'embrouilles.
- [^] # Re: Git sur Windows
  
  Posté par GaMa (site web personnel) le 27 juillet 2011 à 15:00. Évalué à 1.
  
  Juste faire attention à bien configurer ton éditeur/IDE pour qu'il utilise les fins de ligne Unix (\n), tu t'éviteras pas mal d'embrouilles.
  
  On peut aussi configurer git pour qu'il gère automatiquement ce petit soucis :
  http://help.github.com/line-endings/
  
  Matthieu Gautier|irc:starmad
# Git flow

Posté par Maxime G (site web personnel) le 27 juillet 2011 à 21:35. Évalué à 2.

J'utilise git avec la surcouche git-flow :

http://nvie.com/posts/a-successful-git-branching-model/

J'aime beaucoup cette organisation de branches entre develop/feature/release/hotfix et git-flow permet de faire ça simplement (comme j'aime pas avoir à me tordre le cerveau pour être sûr de pas faire de connerie avec des merges...)

http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
# Quelques comparatifs existants

Posté par mikePerdide le 28 juillet 2011 à 13:59. Évalué à -1.

Plutôt que de donner les raisons pour lesquelles je préfère Git, voici deux liens vers des comparatifs de CVS que j'aime bien consulter de temps à autre :
- La PEP 374, une discussion afin de choisir le CVS pour le développement de Python ;
- WhyGitIsBetterThanX, un gros argumentaire pro Git.
- [^] # Re: Quelques comparatifs existants
  
  Posté par ymorin le 28 juillet 2011 à 15:21. Évalué à 1.
  
  WhyGitIsBetterThanX, un gros argumentaire pro Git
  
  En effet, c'est pro-git. Tellement que c'en devient presque de la mauvaise foi. :-)
  
  Et le "gros argumentaire" inverse : Why Git Ain’t Better Than X, rédigé du point de vue d'un afficionados de Bazaar.
  
  Et enfin un argumentaire qui calme les choses : Git vs. Mercurial: Please Relax. Celui-ci est un peu en retard, notamment parce que git n'est plus une multitude de petits binaires comme au début, mais les arguments n'en sont pas moins toujours valables.
  
  Hop,
  Moi.
# fossil?

Posté par devnewton 🍺 (site web personnel) le 28 juillet 2011 à 16:22. Évalué à 3.

Pour les projets persos, je trouve que fossil est vraiment excellent, car mine de rien, administrer un gestionnaire de version, un bug tracker et un site, ça prends beaucoup de temps. Avec fossil, ça se fait tout seul.

Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
- [^] # Re: fossil?
  
  Posté par wilk le 29 juillet 2011 à 10:27. Évalué à 2.
  
  Comment on modifie le wiki et le bug tracker ? Sur leur site je ne vois pas la possibilité en ligne, est-ce qu'il faut passer par une branche et éditer sur cette branche hors ligne comme on le fait en éditant le fichier todo ou une page de doc sur un projet classique ?
  - [^] # Re: fossil?
    
    Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 10:50. Évalué à 2.
    Tu as deux possibilités pour éditer les pages du wiki:
    - tu te connectes (login/mot de passe) et tu peux éditer le wiki en ligne.
    - tu crées des fichiers .wiki et tu les ajoutes au dépôt.
    Ce qu'il faut bien comprendre, c'est qu'un site fossil (par exemple http://fossil-scm.org/index.html/doc/trunk/www/index.wiki ou https://bci.dyndns-server.com/devnewton/fossils/newton_adventure ) est un dépôt.
    
    Tu peux donc choisir d'utiliser toujours un seul dépôt, soit utiliser un dépôt "dev" et un dépôt "prod" par exemple, utiliser un dépôt comme "branche", etc...
    
    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
    - [^] # Re: fossil?
      
      Posté par wilk le 29 juillet 2011 à 14:09. Évalué à 1.
      
      Pour le bug tracker c'est pareil ?
      
      Si plusieurs personnes mettent leur branche en ligne il y aura plusieurs wiki simultanés à synchroniser par la suite ? En tout cas l'idée est intéressante car on fait souvent des aller-retour entre un wiki en ligne et la doc, ça mériterait d'être expérimenté sur d'autres dvcs.
      - [^] # Re: fossil?
        
        Posté par devnewton 🍺 (site web personnel) le 29 juillet 2011 à 14:17. Évalué à 2.
        
        Oui, le bug tracker et le wiki sont versionnés et distribués.
        
        C'est le côté "tout en un sans prise de tête" que j'aime bien. Après je le réserve pour les petits et moyens projets, car ce n'est pas une solution aussi puissante qu'avec des outils spécialisés pour chaque usage.
        
        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Merci à tous

Posté par phoenix (site web personnel) le 30 juillet 2011 à 15:19. Évalué à 4.

Merci à tous de vos réponse.

Je vais tester Mercurial et j'espère ne pas le regretter ;) Au pire j'aurais appris à utiliser un nouveau mode de RCS sinon je serai super satisfait et heureux.
- [^] # Re: Merci à tous
  
  Posté par bat13 le 24 août 2011 à 10:29. Évalué à 1.
  
  Passe donc à mercurial, je ne vois aucune raison de le regretter, bien au contraire.
  Après, si tu dois rebosser avec svn, tu vas trouver ça lourdingue.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.