La liste des options proposées est volontairement limitée : tout l'intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées, ou de l'impossibilité de choisir plusieurs réponses. 76,78% des sondés estiment que ces sondages sont ineptes.
  • # Proposition

    Posté par (page perso) . Évalué à 5.

    Merci à ouasse http://linuxfr.org/~ouasse/ à l'origine de cette proposition de sondage :)
    • [^] # Re: Proposition

      Posté par (page perso) . Évalué à 2.

      oui, merci beaucoup

      étant dans de nombreux projets et ce débat venant souvent sur la table, cela donne des informations intéressantes !

      donc votez ! :)
  • # git et/ou subversion

    Posté par (page perso) . Évalué à 1.

    j'utilise les deux :

    - subversion pour mes projets sur sourceforge

    - git pour mes petits développement locaux.
    Je lui reproche essentiellement une chose : de ne pas gérer l'expansion de mots-clefs
    • [^] # Re: git et/ou subversion

      Posté par (page perso) . Évalué à 4.

      Sais-tu que Git peut servir de client subversion, et donc faire des updates et des commits entre un dépôt local Git vers un dépôt distant Subversion ? Du coup ça permet les branches locales, d'avoir la totalité du dépôt en local, bref, du décentralisé quoi.

      Et sinon, c'est quoi « l'expansion de mots-clefs » dans Subversion ?
      • [^] # Re: git et/ou subversion

        Posté par . Évalué à 1.

        Je suppose qu'il s'agit de l'autocomplétion avec la touche "tab" dans le shell.

        Mais dans ce cas il ne s'agit pas réellement d'une fonction de Subversion mais d'un addon pour bash (ou pour zsh ou autre).
        • [^] # Re: git et/ou subversion

          Posté par . Évalué à 3.

          Non, c'est le fait de mettre des clé/tag dans un fichier source que SVN va remplacer par une données au moment où on lui demande (date, nom du fichier, revision ou même une propriété que l'on set).

          Perso, je suis contre les keywords, c'est plutôt ingérable à la fin même si ça facilite la vie pour identifier des livraisons.
          • [^] # Re: git et/ou subversion

            Posté par . Évalué à 1.

            Les keywords ne cadrent pas du tout avec la manière de faire sous git. Par compte, rien n'empèche d'écrire un script qui injecte des numéros de version lors du processus de création d'une archive.
  • # cpold

    Posté par (page perso) . Évalué à 10.

    je suis déçu, il manque LE système version ultime. Il est universel, il est disponible partout, il est tout puissant, le seul, l'unique : cpold
    http://roland.entierement.nu/blog/2008/01/22/cpold-la-poudre(...)
    • [^] # Re: cpold

      Posté par . Évalué à 1.

      Je pense qu'il va dans :
      mon propre système (lp, tar/diff/patch, etc.) :

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: cpold

      Posté par . Évalué à 2.

      je suis déçu, je m'attendais à récolter des XP (qui n'existent pas) en postant aussi le CPOLD (qui manque cruellement dans la liste des choix).
  • # sccs

    Posté par (page perso) . Évalué à 2.

    Le premier que j'ai utilisé, c'est sccs Source Code Control System. Je crois bien que c'est l'ancêtre de tous les autres.
    • [^] # Re: sccs

      Posté par (page perso) . Évalué à 1.

      quoi ??? un SCM encore plus préhistorique que RCS !
    • [^] # Re: sccs

      Posté par (page perso) . Évalué à 1.

      C'est même sûr que SCCS est l'ancêtre : SCCS date de 72, RCS de 82 et CVS de 86.

      Dire que je m'en sers au taf... certes il fait bien ce qu'on lui demande mais comment dire...

      /me retourne utiliser git pour se sentir au XXIe siècle.
  • # [x] Darcs

    Posté par . Évalué à 9.

    C'est pas sympa de ne pas le mettre dans le sondage, alors qu'il y a eu tout récemment une dépêche à son sujet. :(
  • # [x] RCS

    Posté par (page perso) . Évalué à 2.

    Pour un usage local, il est simple et efficace, et, à ma connaissance, irremplaçable.

    Il n'y a pas que les projets logiciels qui ont besoin de conserver un historique des évolutions, il y a aussi:
    - Les écrits au long cours (cours, mémoires, thèses).
    - Les petits scripts qui évoluent tout le temps.
    - Certains fichiers de configuration.
    - Son carnet d'adresse
    - ...

    Pour ma part, RCS me sert surtout dans le premier cas. Il est un compagnon essentiel des processeurs de textes tels Tex et Roff.
    • [^] # Re: [x] RCS

      Posté par (page perso) . Évalué à 7.

      Git ?
      • [^] # Re: [x] RCS

        Posté par . Évalué à 0.

        Non, mieux: hg :-)
        • [^] # Re: [x] RCS

          Posté par . Évalué à 1.

          J'avais oublié qu'on n'était pas encore vendredi !

          On ne pourrait avoir une case avec un commentaire pour dire pourquoi on plusse ou moinse ?
          • [^] # Re: [x] RCS

            Posté par (page perso) . Évalué à -4.

            > On ne pourrait avoir une case avec un commentaire pour dire pourquoi on plusse ou moinse ?
            non, mais par contre en général lorsqu'on demande de moinser un message le contraire peut se produire.

            note : vous pouvez moinser se message
            • [^] # Re: [x] RCS

              Posté par . Évalué à 6.

              note : vous pouvez moinser se message

              Voilà, c'est fait. A ton service ... :)
            • [^] # Re: [x] RCS

              Posté par (page perso) . Évalué à 3.

              La réciproque est fausse aussi. Il faudrait comparer qui est le plus vite à -10 entre un message qui demande de se faire moinsser et un message qui demande de se faire plusser (mais juste ça hein).

              Envoyé depuis mon lapin.

  • # hg

    Posté par (page perso) . Évalué à 5.

    admettons que svn est en tête pour des raisons historiques (sinon pourquoi ?)

    Bazaar se fait laminer par presque tout le monde (nan mais sérieux, quelqu'un l'utilise par plaisir celui-là ?)

    Mercurial par contre est totalement à la ramasse par rapport à git
    Pourquoi ?
    - git c'est fun ?
    - git c'est roots ?
    - git il fait le café ?
    - mercurial est à la traine ?
    - mercurial n'est pas pratique ?
    - mercurial est trop proche de svn ?
    (cette belle indentation de question me rappel un de mes anciens chefs qui réorganisait constamment son code pour avoir au maximum sous cette forme, la ligne suivante toujours plus longue que la précédente...)


    Bon, il est vrai que je tape souvent sur mercurial. Mais je viens de comprendre un truc (enfin) et j'en profite pour le partager avec vous tous : dans mercurial une branche n'existe que par la présence d'un commit. En gros la branche est une metadata du commit.
    Donc si dans git il est possible de créer par exemple 3 branches locales dans lesquelles travailler plus tard (histoire de préparer son taff quoi), dans mercurial tant qu'on a pas de commit, la branche n'existe pas. Donc si on crée (ou croit créer...) 3 branches, lorsqu'on va vouloir switcher de l'une vers l'autre on va avoir un zoli message nous disant que ça ne fonctionne pas, que la branche est inexistante.
    ☿ hg branch feature1
    marked working directory as branch feature1
    ☿ hg up default
    0 files updated, 0 files merged, 0 files removed, 0 files unresolved
    ☿ hg up feature1
    abandon : unknown revision 'feature1' !

    Ceci explique que lorsqu'on tente d'utiliser hg comme git (y compris avec bookmarks, localbranch, tasks, etc) ça ne marche jamais...

    Finalement, hg et mercurial, s'ils sont équivalents, n'ont pas du tout la même façon de bosser.
    Dans git, on va créer des branches locales nommées, souvent, et parfois à l'avance (histoire d'organiser).
    Dans mercurial on va coder et, si besoin, on va brancher là où on le souhaite, mais au dernier moment je pense.
    Et d'ailleurs, le fonctionnement de base de mercurial fait qu'on ne va pas la nommer, juste utiliser la révision initiale (ou alors utiliser bookmarks, qui permet "simplement" de nommer une révision en fait)

    Bon, dans les deux cas on arrive au même résultat. Mais je pense que si on vient de git et qu'on tente d'utiliser hg de la sorte, on est très vite déçu par hg. Par contre, en comprenant un peu plus comment ça marche, ben c'est intéressant comme manière de travailler. Le point noir par contre c'est que ça force à connaître un peu plus comment fonctionnent les branches, les commits dans mercurial.


    Voilou, c'était juste pour dire que je commençais enfin à comprendre comment mercurial fonctionne (et peut-être même qu'un jour j'arrêterai de troller dessus...)
    • [^] # Re: hg

      Posté par (page perso) . Évalué à 3.

      Tu aimes tellement mercurial que tu utilises le symbole de Mercure comme PS1 ?
      • [^] # Re: hg

        Posté par (page perso) . Évalué à 4.

        ben disons que mon prompt ressemble plutôt à ça dans un dépot hg :
        ... at ... in ~/tmp/dev_hg/repo on default at tip

        La même chose pour git :
        ... at ... in ~/tmp/dev/repo on master
        ±


        Et en bout de prompt j'ai la charge de ma batterie
        ▸▸▸▸▸▸▸▸▸▸▸▸

        [http://stevelosh.com/blog/2010/02/my-extravagant-zsh-prompt/]
        • [^] # Re: hg

          Posté par . Évalué à 2.

          Par curiosité, tu pourras poster ton PS1 ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: hg

      Posté par (page perso) . Évalué à 3.

      Mercurial par contre est totalement à la ramasse par rapport à git

      À mon avis, c'est l'effet de masse, Linux, KDE, Gnome, Fedora sont (ou seront) sous git, du coup, tu te dit que ça doit valoir la peine.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: hg

        Posté par (page perso) . Évalué à 3.

        hum... j'ai l'impression que git était déjà plus connu que mercurial bien avant que kde ou gnome l'utilisent.
        Il est évident que l'effet Torvalds / Linux joue un grand rôle.
        Mais le libre est également connu pour jeter un outil pour prendre l'outil d'à côté qui serait plus intéressant.
        Et concernant l'effet de masse, même si c'est pas forcément identique, côté mercurial il y a par exemple openjdk, netbeans, mozilla. En outre, une intégration plus poussée dans certains ide (ou depuis plus longtemps) et une plus grande portabilité.
        Donc sans parler du coeur de ces deux systèmes, mercurial est à mon avis plus intéressant.
        Donc la raison de git > mercurial (en pdm...) ne serait pas réellement plutôt du au design de mercurial moins apprécié que celui de git ?
        • [^] # Re: hg

          Posté par (page perso) . Évalué à 2.

          l y a par exemple openjdk, netbeans, mozilla.

          Des développements qui attirent beaucoup moins de contributeurs que ceux que j'ai cité,

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: hg

            Posté par (page perso) . Évalué à 2.

            il y a aussi python par exemple

            Le nombre de développeur c'est une chose, mais comme indiqué j'ai l'impression que ça date d'avant que gnome ou kde passent à git. Et c'est ce point là qui est à mon avis intéressant
      • [^] # Re: hg

        Posté par (page perso) . Évalué à 2.

        À mon avis, c'est l'effet de masse, Linux, KDE, Gnome, Fedora sont (ou seront) sous git, du coup, tu te dit que ça doit valoir la peine.

        C'est exactement ça.

        Au début j'étais pro-mercurial, mais pour des raisons politiques, j'ai changé pour git, et depuis je le trouve mieux.

        Je sais qu'à l'époque, je reprochais à git de ne pas permettre comme dans mercurial d'avoir deux têtes dans une seule branche. Mais j'ai compris que git faisait différamment:

        git:
        - on rapatrie les commits distants qu'on stocke dans une branche distante
        - on merge la branche distsante avec la branche locale du même nom

        mercurial:
        - on rapatrie les commits distants qui s'ajoutent au dépôt. Pour les branches qui on divergé, elles se retrouvent avec deux têtes.
        - on merge ces deux commits de tête pour se retrouver dans un cas classique où les branches ne divergent plus.

        Si on ne connaît pas bien git, on peut lui reprocher que le "detached HEAD" ne soit pas aussi biebn géré que le "dual head" sous mercurial. Dans mercurial, si je commite à un autre endroit que HEAD, ce commit sera enregistré comme faisant partie de la branche du commit parent alors qu'avec git, on peut perdre le commit et le voir un jour disparaître par garbage collector.
      • [^] # Re: hg

        Posté par . Évalué à 3.

        Quand bien même ce soit l'effet de masse, savoir que des projets sommes toutes énormes tels que GNOME ou KDE ont dégagé leurs anciens outils pour migrer vers Git est quand même une belle preuve de maturité et d'efficacité de ce dernier.

        On sait que le libre fonctionne au mérite : on prend le meilleur outil, pas celui avec lequel on a un accord.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: hg

      Posté par (page perso) . Évalué à 4.

      Oui, mercurial et git se ressemblent. Mais la structure de git est très différente (tu regardes ton .git, ça n'a rien à voir), et il est en général plus rapide.

      Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack), et tout est bon à prendre quand on sait qu'on doit tout récupérer quand on fait un clone.

      Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web. Alors, au bout de cinq minutes à poireauter, on se demande quand même s'il va y en avoir pour longtemps.

      En revanche, git sur Windows, c'est plutôt la galère, et les Windowsiens apprécient par exemple TortoiseHG. D'ailleurs, ne dépendre que de python, et tout avoir dans un seul exécutable (contrairement aux dizaines et dizaines de binaires et/ou scripts shells pour git) rend le portage vers d'autres plateformes plus aisé.

      J'ai sans doute oublié des tas de choses…
      • [^] # Re: hg

        Posté par (page perso) . Évalué à 7.

        Git, je pense que c'est typiquement un de ces outils codé par des gens qui n'en ont juste rien à talquer des windowsiens, pas par méchanceté, juste parce qu'ils s'en moquent, ce n'est pas leur problème. Mais qui sont prêts à accepter les efforts de gens qui ne s'en moquent pas pour faire le travail de portage.
        • [^] # Re: hg

          Posté par (page perso) . Évalué à 4.

          C'est effectivement très facile de faire un programme qui ne marche pas sous Windows, je pense que la plupart de ce que j'ai écrit a peu de chances de tourner dessus. C'est pas volontaire, sinon j'aurai aussi tenté d'être incompatible avec Mac OS ;-).

          DLFP >> PCInpact > Numerama >> LinuxFr.org

        • [^] # Re: hg

          Posté par . Évalué à 2.

          Franchement, en un sens c'est pas plus mal, ça nous permet à nous, Linuxiens, d'avoir des outils au top.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: hg

        Posté par . Évalué à 2.

        Il mze semble qu'il est plus simple de mettre à disposition un dépot HG via http(s) qu'un dépot GIT.
        • [^] # Re: hg

          Posté par (page perso) . Évalué à 1.

          Euh non. Le dépôt Git, il suffit de le faire servir par un serveur Web et hop, on peut le clone avec une URL HTTP. Mais je ne vois pas bien l'intérêt.
          • [^] # Re: hg

            Posté par . Évalué à 2.

            Quand j'ai regardé (il y a déjà un bout de temps) ce n'était pas si simple avec GIT. Et ce genre de truc est bien pratique si tu veux accéder à ton dépot derrière un proxy/firewall.
            • [^] # Re: hg

              Posté par (page perso) . Évalué à 2.

              Typiquement on donne accès à un dépôt Git en lecture par HTTP pour faciliter l'accès public aux sources, par contre pour modifier on passe généralement par SSH.
              • [^] # Re: hg

                Posté par . Évalué à 2.

                C'est ce qui pour moi donne un net avantage à HG (de mémoire on peut modifier via http).
                • [^] # Re: hg

                  Posté par (page perso) . Évalué à 2.

                  On peut aussi pour Git, avec dav/http. Mais franchement, pourquoi faire compliqué ?
                  • [^] # Re: hg

                    Posté par . Évalué à 2.

                    C'est pas faire compliqueé pour faire compliqué, c'est silmplement parce que certains proxies n'acceptent pas de faire passer le SSH (j'ai l'impression de me répéter).
                    • [^] # Re: hg

                      Posté par (page perso) . Évalué à 2.

                      Autant utiliser un VPN qui passe par http alors !

                      DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: hg

              Posté par (page perso) . Évalué à 1.

              Git était en retard sur ce point, mais maintenant, il y a du "smart HTTP(S)" dans Git comme dans Mercurial (depuis 1.6.quelquechose).
          • [^] # Re: hg

            Posté par (page perso) . Évalué à 2.

            L'intéret ? Pour les truc genre yaourt/aur c'est mieux de mettre l'uri http si elle existe...
          • [^] # Re: hg

            Posté par . Évalué à 3.

            Toi tu n'a jamais eu affaire à des administrateurs systèmes qui n'autorisent que le port 80.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

            • [^] # Re: hg

              Posté par (page perso) . Évalué à 3.

              On a tous eu à faire à des crétins incompétents, ou des adminsys qui obéissent servilement à un crétin incompétent. ;)
      • [^] # Re: hg

        Posté par . Évalué à 3.

        > Git est aussi très efficace pour compresser les deltas (cf. git gc, git repack)
        Pour les opérations réseaux comme clone, pull, push etc ..., le protocole wire de mercurial est sensiblement plus efficace que le protocole git ou même HTTP utilisé par Git.
        De plus, les opérations d'optimisation du stockage sont automatisées dans mercurial (donc plus "newbie-proof"), certes, Git reste un poil plus efficace à ce niveau.

        > Autre truc qui m'énerve avec mercurial, c'est qu'on n'a aucun indicateur de progression quand on clone depuis le web
        Tu as l'extension standard progress pour ça, suffit de l'activer.
    • [^] # Re: hg

      Posté par (page perso) . Évalué à 3.

      Mine de rien, les gens semblent utiliser git à cause/grâce à github. Beaucoup de projets sont disponible sur cette plate forme, ce qui lui donne une très grande visibilité.

      Concernant git versus mercurial, il y à un très bon article de steve losh à ce sujet: http://stevelosh.com/blog/2010/01/the-real-difference-betwee(...)

      J'utilise personnellement mercurial, parce que je le trouve plus simple à configurer/étendre que git, et que les extensions existantes me permettent de faire ce que je souhaites facilement.
    • [^] # Re: hg

      Posté par . Évalué à 1.

      J'utilise mercurial depuis 2 ans et je n'ai jamais fait de branche... je fais un clone du repository duquel je veux faire une branche et je l'utilise comme si c'était une branche. Au final on peut voir le un repo comme une branche et la gestions des différentes branches est à mon humble avis plus simple de cette façon.
      • [^] # Re: hg

        Posté par (page perso) . Évalué à 3.

        Mais un clone est une branche, que dis-je, une bouture ;)
  • # IPoT

    Posté par . Évalué à 2.

    Besoin de retrouver son code source à un moment donné ? IPoT est votre ami. Fonctionne également avec les sites Internet, les conversations IRC, les mails... bref, tout ce qui peut passer sur IP, y compris ce qui n'avait pas été prévu pour à la base.
  • # Prononciation de Git

    Posté par . Évalué à 3.

    Une question qui me taraude depuis que j'utilise (avec grande satisfaction) Git :

    Vous prononcez « jite » ou « guite » ?
  • # Git et Mercurial

    Posté par (page perso) . Évalué à 3.

    • Mercurial sous Windows, au boulot, une bonne centaine de repos, à chaque fois quelques milliers de fichiers . Interface graphique sympa, pas de souci de performance (sauf peut-être dans la mise à jour des icônes dans l'explorateur, et dans le lancement de l'utilitaire de configuration), ligne de commande agréable. Pas de souci pour un travail en équipes d'une dizaine de personnes, au fur et à mesure qu'elles gagnent en expérience elles apprécient de plus en plus l'outil.

    La capacité d'aller lire et modifier le code source pour déboguer un problème de configuration serveur a été un gros plus. (Mercurial étant dans ce cas installé au sein d'une installation Python standard, et non pas avec un Python intégré.)

    • Git sous Linux, chez moi (et quelques essais sous Windows), une demi-douzaine de repos, à chaque fois quelques dizaines / centaines de fichiers. Interfaces graphiques qui s'améliorent (pas essayées récemment), pas de souci de performance (mais bon, en solo avec quelques commits... c'est pas vraiment un challenge).

    Le format de stockage des données, les concepts derrière Git, me semblent nettement plus propres, agréables, et intuitifs que ceux de Mercurial.

    Par contre, la ligne de commande de Git est nettement plus hardcore, avec des listes d'options qui calment, jusqu'à ce qu'on prenne ses marques.
    • [^] # Re: Git et Mercurial

      Posté par . Évalué à 0.

      * mercurial: plus facile d'accès, moins intimidant, on peut tout de suite commencer. On sent vraiment le côté user-friendly voulu par les auteurs. De la très bonne documentation, entre le wiki, le hgbook [http://hgbook.red-bean.com], et des tutoriels du type [http://hginit.com]

      * git: souvent présenté de façon plus technique, plus touffue. Beaucoup de commandes, les man pages peuvent sembler un peu plus repoussantes vu le nombre de switches. Il faut apprendre à faire le tri et se concentrer sur l'essentiel. On peut avoir sans entrer dans les détails une bonne vue d'ensemble via [http://progit.org/book]

      C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent (commit, tree, blobs etc...). Pour les fonctionalités relatives à la manipulation de l'historique ou aux merges avancés, c'est carrément indispensable. Franchement, le data-model semble particulièrement élégant/séduisant, et paradoxalement assez simple.

      Une fois qu'on a dépassé l'étape de la découverte, on se rend vite compte que les deux scms répondront assez facilement à la plupart des besoins.

      Ensuite, d'un point de vue pragmatique, l'énorme avantage de hg est que vues ses dépendances (python + je crois un peu de C), il est utilisable sur tous les os, il peut être facilement intégré dans des IDEs. On peut trouver des GUIs pratiques etc...
      C'est exactement là ou git pêche un peu: par exemple, même si des efforts ont été faits ou sont en cours pour rapatrier certaines fonctionalités dans des libs, on a droit à du perl, du shell script etc... De plus, git a été développé pour linux, msysgit (le portage officiel sous windows) n'est pas aussi performant mais reste utilisable.. Les GUIs sont plus rares et semblent moins abouties.

      Bref, git semble plus puissant que hg pour les fonctionnalités avancées (grâce à son data model sous-jacent avec plus de potentiel) mais il est d'un abord pas facile (doc, déploiement sur des os différents etc..). Au contraire, hg semble avoir moins de potentiel d'un point de vue purement technique, par contre l'utilisateur est choyé (déploiement aisé, doc, outils etc...)
      • [^] # Re: Git et Mercurial

        Posté par (page perso) . Évalué à 2.

        C'est peut être subjectif, mais en tout cas j'ai trouvé que pour pouvoir se servir de git, il est rapidement très utile de se donner la peine de comprendre le data-model sous-jacent
        J'ai lu en bouquin sur git, l'auteur avait justement choisi (et justifié son choix) de commencer par le "data model" de git et ça m'a rendu beaucoup plus efficace.

        J'ai utilisé Mercurial et Git, d'abord Mercurial pour ses commandes beaucoup plus intuitives (surtout quand on a utilisé Subversion avant) mais git une fois maîtrisé est juste beaucoup plus puissant.

        Le passage à git dans mon boulot a d'ailleurs arrêté la pratique des GUI/intégration à un IDE et depuis les fichiers commités par erreur sont beaucoup plus rares (pourtant il y a effectivement des GUI, que je n'ai testé que pour leur affichage de l'historique).

        DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Nouveau sondage ?

    Posté par . Évalué à 1.

    On ne devait pas changer de sondage tous les 15 jours à la base ?

Suivre le flux des commentaires

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