Gestion de versions Nouveautés autour de Git

Posté par (page perso) . Édité par Davy Defaud, baud123, Xavier Claude, MrLapinot, Christophe Guilloux, patrick_g et Maxime. Modéré par baud123. Licence CC by-sa
46
30
oct.
2012
Gestion de versions

La semaine passée, à un jour d’intervalle, deux petites nouvelles concernant l’actuel chouchou des gestionnaires de version, à savoir Git, sont passées un peu inaperçues. Ce dernier vient de sortir, le 21 octobre, en version 1.8.0, et Gitlab, application Web d’autogestion de projets sous Git, passe, lui, en version 3.0 depuis le 22 octobre.

Les nouveautés de ces deux logiciels sont un peu plus détaillées dans la seconde partie de la dépêche.

Git 1.8.0

Cette nouvelle version de Git, gestionnaire de version sous licence GPL v2 apporte un nombre conséquent de corrections de bogues et de nouveautés à tous les niveaux, de l’interface graphique à l’envoi de courriels, en passant par la performance. Si vous voulez la liste exhaustive, référez‐vous aux notes de version. En synthèse, on peut noter :

  • ajout de Windows (Win 32) et GNOME Keyring, pour l’aide à l’identification — credential helpers — ;
  • améliorations et ajouts dans l’interface graphique ;
  • nouvelles options pour les sous‐commandes cherry-pick, difftool, grep, log, rebase et le daemon git ;
  • concernant la gestion des courriels, git am nettoie le sujet d’un message et git send-email demande une confirmation si l’adresse du destinataire n’est visiblement pas une adresse de courriel ;
  • git svn est maintenant compatible avec Subversion 1.7 ;
  • le portage sur le système d’exploitation de HP NonStop.

logo Git

Le mainteneur de Git, Junio C. Hamano, a aussi annoncé que la prochaine version 1.9._x_, verrait un changement de comportement de la commande push. Celle‐ci ne devrait plus permettre d’« écraser » accidentellement une branche sur un serveur distant. De plus, la commande git branch --set-upstream a été marquée comme obsolète — deprecated — et ne devrait plus exister sous peu. Elle peut être remplacée avantageusement par git branch [-u | --set-upstream-to], qui propose un arrangement des arguments plus « sensé ».

Gitlab 3.0

Basé sur Ruby on Rails et Gitolite, Gitlab est une application Web sous licence MIT qui permet d’héberger et de gérer soi‐même ses projets « versionnés » avec Git. Une sorte de clone du très connu Github. Plus de 300 commits sont annoncés depuis la précédente version. Les changements se situent à la fois côté utilisateur et sous le capot, dont voici une rapide synthèse.

Logo Gitlab

Côté utilisateur

  • amélioration de la navigation dans les fichiers ;
  • mise à jour de l’interface de programmation, avec plus de fonctions exposées ;
  • présence d’un éditeur Web ;
  • prise en charge des groupes de projets.

Sous le capot

  • prise en charge non officielle de PostgreSQL ;
  • augmentation significative des performances concernant les commits ;
  • réorganisation et nettoyage de code ;
  • correction d'un bogue critique lors de la suppression ou de l’ajout de clefs SSH.

Capture d’écran du tableau de bord de Gitlab

Dashboard de Gitlab

Alternatives

Parmi les alternatives libres à Gitlab et proposant comme lui Git, notons Indefero, dont l’auteur, Loïc d’Anterroches vient nous entretenir souvent ici, mais aussi Gitorious, sous AGPL, ou encore le toujours plus libre GNU Savannah, sous GPL v2+. Parmi les non‐libres, citons le difficilement contournable Github, l’outsider Bitbucket, l’ogre Google code et le vénérable SourceForge. Sur le Wikipédia anglophone, vous trouverez une page de comparaison presque exhaustive !

  • # Utilisateurs de Gitlab ?

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

    Je viens de voir que le code source de Gitlab était hébergé sur… Github. C'est dommage de ne pas respecter le principe du "Eating your own dog food", mais j'en viens à me demander : qui utilise Gitlab ?

    • [^] # Re: Utilisateurs de Gitlab ?

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

      ça me choque pas, ils peuvent quitter GitHub quand ils le souhaitent. Et pour l'usage c'est bien pratique pour les développements non ouverts au publique comme on utilise Redmine, Trac et autres.

      • [^] # Re: Utilisateurs de Gitlab ?

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

        L'intérêt du dogfooding est double : d'une part en tant qu'utilisateur du produit, tu vois directement ce qu'il faut améliorer et tu expériences directement les bugs. Et d'autre part, ça montre aux potentiels utilisateurs que c'est un produit au moins aussi bon que la concurrence.
        Là, je vois qu'il s'agit d'un clone de github et je me dis qu'il n'est certainement pas au niveau de github puisqu'ils ne l'utilisent même pas.

        • [^] # Re: Utilisateurs de Gitlab ?

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

          tu expériences directement les bugs

          Tu fais l'expérience des bugs, ou tu subis les bugs, comme tu voudras, mais « expériencer », c'est un verbe qui n'existe pas en français.

          • [^] # Re: Utilisateurs de Gitlab ?

            Posté par . Évalué à  9 .

            C'est du JCVD. T'es vraiment pas aware comme type.
            http://www.echolaliste.com/x28.htm

          • [^] # Re: Utilisateurs de Gitlab ?

            Posté par . Évalué à  9 .

            " J'adore le chien. Tu bois une biere et tu en as marre du gout. Alors tu manges du chien. Le chien c'est doux et salé, fort et tendre,comme une femme. Manger des chien, it's a really strong feeling. Et apres tu as de nouveau envie de boire de la bière. Le chien c'est le mouvement perpétuel à la portée de l'homme ".

    • [^] # Re: Utilisateurs de Gitlab ?

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

      github et gitlab ne fonctionnent pas exactement de la même manière. github héberge sur le web ton dépôt (+social) alors que gitlab te propose une interface similaire à installer sur ta propre machine.

      Je pense que l'intérêt est là.

      Pour le public, open-source, on reste sur github qui a pour avantage d'être tourné vers le social. Mais dans le cas d'un dépôt privé, d'une part on paie et d'autre part on n'a pas besoin du social, car justement le but est de ne pas laisser son code transparaitre. Donc, dans le cas d'un dépôt privé, ça peut devenir intéressant de gérer ce genre d'outils.

      L'autre cas, qui ressemble pourrait être celui d'un intranet d'une petite startup.

      Plus simplement, installé en local sur ton ordi si tu veux du code compatible git mais que tu es un peu frileux de tout faire en ligne de commande et que tu aimes ce genre d'outils (mon cas). Comme ça, si comme moi tu as une mémoire tampon, on peut très bien imaginer que tu y mets des fichiers de configs sensible que tu commentes et suit dans le temps.

      Un cas con dans lequel ça pourrait être utile, ça serait dans l'enseignement. Le prof au lieu de donner et ramasser des tp à l'arrache crée une instance gitlab et demande à ses élèves de se créer un compte et de publier leur tp dessus. En plus, ça les formerait un peu à comprendre que la partie rédaction est importante dans un projet.

      Personnellement, j'utilise github pour mes petits projets et autres codes, mais je trouve que c'est une très bonne idée et comme je suis un peu entrain de restructuré mon ordi et mon serveur, j'avoue que je m'intéresse de près à ce genre d'outils.

      La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick

      • [^] # Re: Utilisateurs de Gitlab ?

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

        Je ne remets absolument pas en question l'intérêt de ce logiciel ! C'est très bien, je me réjouis de voir ce genre de logiciel (actuellement j'utilise du redmine pour un besoin similaire qui me permet d'avoir des dépôts git et svn).

        Ce que je reproche c'est juste qu'ils ne l'utilisent même pas eux. Alors oui, y'a le côté social de GitHub, mais c'est tout. Mais ils perdent tous les bienfaits du dogfooding sur la crédibilité et le retour d'expérience.

      • [^] # Re: Utilisateurs de Gitlab ?

        Posté par . Évalué à  1 .

        Oui l'interêt de Gitlab, c'est l'aspect privé (et éventuellement local), d'ailleurs il me semble que par défaut il n'y a pas d'accès anonyme à l'interface (à vérifier).
        Github propose aussi des dépôts privés mais contre un abonnement.

        C'est la solution que j'ai choisis au boulot et connecté en LDAP (sur une AD…) pour la gestion des comptes utilisateur ça remplis parfaitement son rôle.
        Le petit plus par rapport aux alternative c'est l'interface agréable et que tout le monde connait puisqu'elle copie s'inspire de Github.
        Il y aussi le système de ticket qui n'est pas présent sur toutes les solutions concurrentes (Gitorious par exemple)

      • [^] # Re: Utilisateurs de Gitlab ?

        Posté par . Évalué à  2 .

        Bitbucket permet d'avoir des repos privés avec du social (mais limité en contributeurs) et des repos public sans limite de contributeurs.

        Ce projet a un intérêt certain, mais reste très en retrait de GitHub et Bitbucket (j'ai testé les 3). D'autant plus qu'il nécessite d'être couplé à un mécanisme de sauvegarde et un minimum de sécurisation côté serveur, afin de garantir suffisamment le code…
        Pour moi, ses places de prédilection sont :
        _ hébergé sur sa propre machine
        _ sur un serveur d'entreprise
        Par contre, sur un serveur perso (hébergé ou à la maison), c'est un peu plus compliqué à mettre en œuvre.

    • [^] # Re: Utilisateurs de Gitlab ?

      Posté par . Évalué à  4 .

      Dans une certaine mesure, c'est pas très important. Du jour au lendemain, le dépôt de référence peut très bien devenir celui de gitlab, et de la même façon, les contributions pourront aussi bien arriver via github, et ensuite être reversées sur le dépôt de référence, c'est le principe même de la décentralisation. Dans la mesure où le projet est jeune et éventuellement instable, il est peut être prudent de ne pas mettre des bâtons dans les roues des éventuels premiers contributeurs, et les faire participer via la plateforme de référence en attendant.

    • [^] # Re: Utilisateurs de Gitlab ?

      Posté par . Évalué à  1 .

      Aussi, ils peuvent commencer par utiliser Github puis passer à Gitlab quand leur produit est plus mature (mais là ça a déjà l'air assez mature donc c'est étrange).

      "Never trust a statistic you haven't faked yourself."

      • [^] # Re: Utilisateurs de Gitlab ?

        Posté par . Évalué à  6 .

        Une tentative d'explication.

        GitLab est un projet pour déployer sa propre plateforme mais les membres n'ont peut-être pas envie d'en administrer une publique. Il s n'ont peut-être pas l'ambition de faire du business avec.

        A la différence de Gitorious ou In defero par exemple qui fournissent une forge et un hébergement.

        Ca expliquerait pourquoi ils ne sont pas listés ici
        http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
        mais ils devraient l'être ici par contre:
        http://en.wikipedia.org/wiki/Forge_(software)

      • [^] # Re: Utilisateurs de Gitlab ?

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

        En fait, c'est l'inverse. Le code de gitlab était hébergé sur une instance lors des toutes premières versions de gitlab (les 0.x). Mais gitlab est fait pour des projets privés et non pas des projets Open-Source. Du coup, quand ils ont commencé à avoir des contributions externes, ça a posé problème et les créateurs de Gitlab ont donc décidé de passer leur code sur github pour favoriser les contributions externes.

        • [^] # Re: Utilisateurs de Gitlab ?

          Posté par . Évalué à  3 .

          Pourquoi se limiter à des projets privés ? C'est dommage de leur part.

          Le problème c'est que, même avec une instance publique, les contributeurs devront passer l'étape d'inscription avant de contribuer alors que sur Github ils peuvent contribuer tout de suite.

          "Never trust a statistic you haven't faked yourself."

    • [^] # Re: Utilisateurs de Gitlab ?

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

      En plus de toutes les raisons citées précédemment, il peuvent aussi vouloir s'inspirer fortement de ce que fait GitHub. À ce titre, il est certainement plus pratique d'utiliser GitHub afin de mieux connaître ce que l'on souhaite reproduire.

  • # Qu'est-ce qu'utilisent les plus gros projets ?

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

    Il est frappant de voir que les plus gros projets (Linux ou Xorg par exemple) n'utilisent pas les forges web, mais seulement gitweb et des pull request par mail (git request-pull).
    Pourquoi, à votre avis ?

    • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

      Posté par . Évalué à  6 . Dernière modification : le 30/10/12 à 17:59

      Parce que les premiers codent le noyau et n'ont pas d'environnement graphique, que GitHub n'est pas accessible en mode texte et que les seconds utilisent une version en dev de cet environnement qui ne fonctionne pas, que GitHub n'est toujours pas accessible en mode texte.

      C'est le principe du "dogfooding"

      J'ai juste ?

      • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

        Posté par (page perso) . Évalué à  10 . Dernière modification : le 30/10/12 à 18:06

        Github est accessible en mode texte pour l'essentiel depuis peu : https://gist.github.com/3342247

        Linus Torvalds a dit tout le mal qu'il pensait de la façon dont github pervertit la notion de pull request :
        https://github.com/torvalds/linux/pull/17#issuecomment-5654674

        I don't do github pull requests. github throws away all the relevant information,
        like having even a valid email address for the person asking me to pull.
        The diffstat is also deficient and useless. Git comes with a nice pull-request generation
        module, but github instead decided to replace it with their own totally inferior version.
        As a result, I consider github useless for these kinds of things. It's fine for hosting,
        but the pull requests and the online commit editing, are just pure garbage.
        I've told github people about my concerns, they didn't think they mattered, so I gave up.
        Feel free to make a bugreport to github.

        Linus

        • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

          Posté par . Évalué à  4 .

          Très intéressant !
          J'imaginais même pas qu'il puisse y avoir une réponse sérieuse à ma remarque.

          Sinon pour ceux qui ne savent pas comme moi ce qu'est exactement un "pull request"
          http://git-scm.com/book/fr/Git-distribu%C3%A9-Contribution-%C3%A0-un-projet
          http://www.kernel.org/pub/software/scm/git/docs/git-request-pull.html

        • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

          Posté par (page perso) . Évalué à  2 . Dernière modification : le 30/10/12 à 18:21

          Suivi de

          the way the github web interface work, those commits are invariably pure crap

          the quality of stuff I have seen from people who use the github web interfaces has been so low that it's not worth my time.

          right now github is a total ghetto of crap commit messages and unreadable and unusable pull requests.
          And the fact that other projects apparently have so low expectations of commit messages that these
          things get used is just sad. People should try to compare the quality of the kernel git logs with some other projects,
          and cry themselves to sleep.

          I have yet to see any project that does a better job of doing good commit messages than the kernel or git.
          And I've seen a lot of projects that do much worse.

          What I dislike about the github thing is that it's not "crap happens, we'll try to minimize it",
          it's "crap absolutely WILL happen".

          Look here for a good example of a recent valid pull request:
          http://groups.google.com/group/linux.kernel/browse_thread/thread/c3de7bbe9bb73cf5/1d61f01ea9ec3c67?show_docid=1d61f01ea9ec3c67&pli=1
          where that pull request contains:
          - the real person with a real email asking me to pull
          - the explanation of why I should pull
          - a shortlog of the changes (a single line)
          - a proper diffstat it doesn't have silly links to other information, it has the information.

          je cite donc Benjamin Herrenschmidt dans son mail :

          Hi Linus !
          
          It looks like my previous fix for the lazy irq masking problem wasn't
          quite enough. There was another problem related to performance monitor
          interrupts acting as NMIs leaving the flags in an incorrect state.
          Here's a fix that finally seems to make perf solid again.
          
          The following changes since commit 4e25651b70b8d6ded7229ead8181619e121b648d:
          
            Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu (2012-05-11 09:28:35 -0700)
          
          are available in the git repository at:
          
          
            git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
          
          for you to fetch changes up to 7c0482e3d055e5de056d3c693b821e39205b99ae:
          
            powerpc/irq: Fix another case of lazy IRQ state getting out of sync (2012-05-12 09:40:41 +1000)
          
          ----------------------------------------------------------------
          Benjamin Herrenschmidt (1):
                powerpc/irq: Fix another case of lazy IRQ state getting out of sync
          
           arch/powerpc/kernel/entry_64.S |   44 ++++++++++++++++++++++++++++------------
           arch/powerpc/kernel/irq.c      |   13 ++++++++++++
           2 files changed, 44 insertions(+), 13 deletions(-)
          
          

          ad lib, je pense qu'on a compris :)

          • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

            Posté par . Évalué à  3 .

            pure crap
            it's crap absolutely WILL happen".
            ad lib, je pense qu'on a compris :)

            Ad crapitum me parait plus judicieux

          • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

            Posté par . Évalué à  3 .

            Et il pense vraiment qu'en échangeant github par git request-pull qui demandent exactement les mêmes informations et produisent la même chose (sous une présentation différente) ça changerait quelque chose au contenu ?

            • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

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

              Il me semble, à lire le fil de discussion, que Linus Torvalds est confronté à un problème que la plupart des projets libres n'ont pas : trop de contributions à gérer.
              En conséquence, il met en place un genre de filtre passe haut, en refusant d'examiner les contributions qui ne sont pas de grande valeur, avec notamment le critère de la qualité de la présentation des commits : un corps de moins de 72 caractères de large, décrivant complètement le patch (parfois vingt lignes pour un patch d'une seule, dit-il) et une ligne de résumé de moins de 50 caractères séparée du corps.

              En l'espèce, Torvalds chante les louanges de github en tant qu'hébergeur, mais reproche à cette plateforme 1) de ne pas permettre facilement de saisir des messages de commit propres et, 2) si j'ai bien compris, de déplacer vers ses pages de discussion certaines informations qui seraient mieux rangées dans un message de commit (mais pas nécessairement toutes, vu que pour le noyau, les mailing lists servent également à discuter de patches en dehors des messages de commit).

              • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

                Posté par . Évalué à  4 .

                Bha oui on est d'accord ce n'est clairement pas un problème d'outil. Si tu fais les choses proprement avec l'un des outils tu le feras proprement avec un autre. Je ne vois aucune différence. Et c'est bien le sens de ma remarque.

                • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

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

                  Oui, d'accord là-dessus. Linus Torvalds reproche à github de ne pas avoir donné suite à ses remarques. Enfin, reproche, c'est un grand mot, ils font ce qu'ils veulent, et lui, il se sert de github uniquement pour publier.

                  • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

                    Posté par . Évalué à  2 .

                    reproche à github de ne pas avoir donné suite à ses remarques

                    Ils ne visent tout simplement pas la meme categorie d'utilisateurs (et c'est tres bien comme ca). En l'etat il semble possible de faire des pull requests sur github qui soit dans le format souhaite par Linus, mais ca ne force pas la main de l'utilisateur.

                    Le projet libre auquel je participe est sur Github et on utilise/accepte les pull requests. Si ca nous obligeait aux meme criteres que pour les patchs que recoit Linus, on aurait a peu pres 0 contributeurs externes (et je ne parle meme pas d'avoir la meme attitude que la lkml, les utilisateurs etant bizarrement peu receptifs a l'excuse "j'ai tellement d'emails et de boulot a gerer que je dois me comporter comme un gros connard pour y arriver").

              • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

                Posté par . Évalué à  2 .

                D'ailleurs, pourquoi git ne reformatte-t-il pas automatiquement les messages de commits pour que ca rentre dans les paramètres ? Si c'est tellement mal vu et si c'est tellement dérangeant, pourquoi ne pas forcer la main en reformattant automatiquement lors du commit ?
                Ca ne pas doit être bien compliqué, surtout si on ne prend pas en compte les traits d'unions etc…

                Personnellement, je trouve que github est une des meilleures choses qui soit arrivée aux projets libres depuis git. Depuis que y'a github et gitorious, j'ai participé a des projets même pour ne corriger qu'une faute de typographie d'1 lettre. Chose que je n'aurai jamais fait si j'avais a sortir un patch par mail, m'inscrire à la mailing list etc. Et pourtant, ca fait un faute en moins dans un README, c'est toujours ca de travail de relecture en moins pour le developpeur principal qui a surement d'autre chose à faire que vérifier toutes les typos dans les README/commentaires ou autre.

    • [^] # Re: Qu'est-ce qu'utilisent les plus gros projets ?

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

      On peut imaginer que la plupart des gens codant Linux ou Xorg bossent avec leurs outils (qu'ils ont développé pour certains) et qu'ils sont donc bien plus productif avec. Contrairement à beaucoup d'autres projets bien plus jeune avec des contributeurs moins expérimentés avec ces outils.

      « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

  • # Gitlab recommend at least 1Gb ram

    Posté par . Évalué à  4 . Dernière modification : le 30/10/12 à 18:03

    Bon, je découvre gitlab, ça me semble un bon moyen de pousser toute l'équipe à utiliser git.
    Le projet semble très bon, intéressant mais sur la procédure d'installation, je lis :

    We recommend to use server with at least 1GB RAM for gitlab instance.

    Pourquoi ?

    J'ai eu des problèmes similaires avec redmine, et je trouve qu'il nécessite également énormément de ram par rapport aux services rendus.

    Bientôt un raspberry ne sera bon qu'a afficher l'heure si on continu à ce train là.

    • [^] # Re: Gitlab recommend at least 1Gb ram

      Posté par . Évalué à  9 . Dernière modification : le 30/10/12 à 18:06

      On est pas vendredi, mais c'est marqué, et c'est la même raison que pour Redmine : «Gitlab 3.0 : Basé sur Ruby on Rails»

      Oui bon ça va, je sors

      • [^] # Re: Gitlab recommend at least 1Gb ram

        Posté par . Évalué à  2 . Dernière modification : le 30/10/12 à 18:18

        J'avais pas osé.

        La solution est donc d'utiliser JRuby. C'est ce qu'on avait fait pour Redmine sur un PC Windows et ca tenait très bien la charge pour 10 personnes.

        Du coup tu n'a plus besoin d'1 Go mais de 2 comme ça.

        Plus sérieusement c'est quoi cette manie de se plaindre sans arrêt pour de la RAM.
        Ici aussi http://linuxfr.org/nodes/96205/comments/1404127

        Et chez nous on a un gros projet qui réclame une JVM à 4 Go pour tourner en prod et ca fait un énorme pataquès.
        Ca coûte quoi 1Go de Ram aujourd'hui ?
        Les sysadmins touchent des primes à l'octet économisé ou quoi ?

        • [^] # Re: Gitlab recommend at least 1Gb ram

          Posté par . Évalué à  9 .

          Ce n'est pas un question de cout mais une question d'optimisation de l'utilisation des ressources.

          Pourquoi imposer 1Go de RAM et 4 CPUs pour faire tourner un service web quand on peut le penser intelligemment pour qu'il n'utilise que 512Mo et 1 CPU sur une machine dont la consommation sera moindre ?

          Pour le même prix, tu pourras mettre en place un serveur supplémentaire pour faire de la répartition de charge et un serveur pour gérer tes sauvegardes.

          • [^] # Re: Gitlab recommend at least 1Gb ram

            Posté par . Évalué à  6 .

            Malheureusement comme me répondent certains clients : «parce qu'un serveur avec XXGo de RAM ça coûte rien, contrairement au salaire d'un dev» (typiquement 64Go à moins de 150€/mois chez un célèbre hébergeur français).
            Bref, le temps c'est de l'argent, alors que la RAM vaut de moins en moins.

            Perso je serais d'avis d'essayer de bien penser le truc dès le départ, mais bon…

            • [^] # Re: Gitlab recommend at least 1Gb ram

              Posté par . Évalué à  3 .

              Oui, enfin ça dépend quoi…

              Ici, il y a quand même le choix au départ d'embarquer Ruby et Rails comme dépendance. A partir de là, même en "pensant bien le truc" tu as un environnement pas mal lourd. Mais ça t'apporte quand même pas mal d'avantages par rapport à une approche plus bas niveau.

              Perso je choisis pas les mêmes outils et je code pas pareil si je dois faire une webapp avec webservices ou si je dois écrire un bout de code qui doit tourner sur Arduino. Et clairement ici quand je vois la description du projet, le choix des outils ne me parait pas insensé. Après rien ne t'empêche de faire la même chose avec des scripts CGI en assembleur, mais ce serait pas mon choix non plus.

              • [^] # Re: Gitlab recommend at least 1Gb ram

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

                Plutôt FastCGI : tu vas quand même pas forker et relire les données à chaque requête !

              • [^] # Re: Gitlab recommend at least 1Gb ram

                Posté par . Évalué à  4 .

                Je suis tout à fait d'accord. Les gens ont tendance à voir 2 qualités logiciel : la correction et la performance. Il y a en un tas d'autres qui peuvent être plus importants que la performance (parce que pour la correction c'est tout de même important). La maintenabilité, la facilité d'écriture en fonction des compétences que l'on a, la facilité à faire des tests, la sécurité, du temps que l'on a a y consacrer,… Tout les projets n'ont pas pour finalité d'être installable sur une montre qui consomme 0,6 Watt a pleine charge.

                Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Gitlab recommend at least 1Gb ram

              Posté par . Évalué à  -7 .

              Perso je serais d'avis d'essayer de bien penser le truc dès le départ, mais bon…

              optimiser juste pour la beaute du geste, ca sert pas a grand chose.
              Sur, tu peux faire tourner ton machin dans 64Mo de ram sur un 386, mais ca va te couter un bras en dev, tout ca pour tourner au final virtualise sur un octo coeur avec 64Go qui passe au final son temps a branler le mammouth.
              Et c'est pas delirant non plus de faire des recommandation qui partent du principe qu'il peut y avoir des pics de charges ponctuels, et donc prevoient en consequence.

              Soit t'as une equipe d'ops dediee qui va allouer une VM sur un gros machin qui est de toutes facons la, soit tu fais ca a la rache sur un desktop planque sous ton bureau, et je parie une couille qu'il a un core2duo avec 2Go de ram mini.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Gitlab recommend at least 1Gb ram

          Posté par . Évalué à  2 .

          Sur beaucoup de machines modernes (le raspberry pie était donné en exemple), la RAM est soudée, fixe et non extensible. Sur des machines un peu moins modernes, la RAM est limitée par le chipset (par exemple 3 Go sur les machines à base de 945GM, pas si ancien que ça), et pourtant elles devraient pouvoir continuer à rendre les mêmes services qu'autrefois.

          Je comprends le raisonnement disant que le salaire d'un dev coûte plus cher que le hardware (ceci parce qu'on ne paye pas l'énergie ni les matières premières à leur vrai prix : on ne paye que l'effort nécessaire à leur extraction, mais rien correspondant à la ressource elle-même, qui est finie et non renouvelable). Mais à la fin on n'a qu'une planète => sans aller jusqu'à dire qu'il faut tout coder en assembleur, ce serait bien que les devs fassent un petit peu attention aux ressources qu'ils consomment pour éviter de nous faire changer de machine tout le temps ! Un raspberry pie avec 256 Mo de RAM devrait pouvoir être largement suffisant pour ce genre d'usage serveur ! (c'est quand même moins contraint qu'un C64 ! :)

          • [^] # Re: Gitlab recommend at least 1Gb ram

            Posté par . Évalué à  6 .

            Sur beaucoup de machines modernes […], la RAM est soudée, fixe et non extensible. Sur des machines un peu moins modernes, la RAM est limitée par le chipset […].

            Tu ne trouve pas ça triste comme évolution ? On crie au loup quand Apple crée des téléphones avec une batterie non-amovible mais il est loin d'être le seul. Avoir la mémoire soudée c'est aussi devoir tout changer quand celle-ci est morte ou quand on veut gagner un peu en mémoire.

            Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

            • [^] # Re: Gitlab recommend at least 1Gb ram

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

              La batterie non-amovible fait a priori partie d'une stratégie d'obsolescence programmée chez Apple et ce depuis le début avec les batteries d'iPod programmées pour durer 18 mois (Apple a du mettre en place un système de remplacement suite à un procès), jusque récemment avec le nouveau connecteur de l'iPhone 5.

              Du côté du Raspberry, je pense personnellement que c'est loin d'être fait dans un contexte stratégique de programmer l'obsolescence, mais plus d'économie de coûts et de place, car rajouter un connecteur amovible, mine de rien ca a un impact sur ces deux points. Pour moi, si ta RAM meurt trop tôt, tu fais fonctionner la garantie et si la quantité de RAM ne te convient pas, il y a d'autres solutions. Et ce n'est pas comme si on ne pouvait plus rien faire tourner de nos jours avec 512 Mo. Il y a toujours plein de distros Linux taillées pour ce type de matériel. Alors que chez Apple, plus de batterie => poubelle et anciens câbles => poubelle. Les autres constructeurs ont démontré que l'on pouvait faire aussi bien, voire mieux, que les produits de la pomme, avec une batterie amovible, un connecteur standard, etc.

              Bref, tu ne cherches pas des poux sur la bonne tête.

              • [^] # Re: Gitlab recommend at least 1Gb ram

                Posté par . Évalué à  0 .

                La batterie non-amovible fait a priori partie d'une stratégie d'obsolescence programmée[…]chez Apple, plus de batterie => poubelle

                L'obsolescence programmée n'a pas lieu d'être puisque tu peux faire changer ta batterie sur les produits apple.
                http://support.apple.com/kb/index?page=servicefaq&geo=France&product=iphone&select=BATTERY_REPLACEMENT#top

                • [^] # Re: Gitlab recommend at least 1Gb ram

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

                  Merci donc à Elizabeth Pritzker, car sinon, cela n'aurait pas été le cas. Il a fallu qu'Apple se prenne un procès pour qu'il le fasse. Ça faisait donc partie de leur stratégie initiale, qui a été contrée dans ce cas précis.

                  Je cite le lien donné en exemple pour ceux qui n'ont pas cliqué :

                  À la suite du procès en recours collectif intenté par Elizabeth Pritzker devant la justice américaine, Apple mit en place un service de remplacement des batteries périmées.

              • [^] # Re: Gitlab recommend at least 1Gb ram

                Posté par . Évalué à  2 .

                Et pourquoi chez Apple ce serait obligatoirement de l'obsolescence programmée ? Eux aussi (surtout eux en fait) ils doivent faire des économies de d'espace et d'argent. Le nouveau connecteur c'est justement un exemple d’économie d'espace. Ils ont quand même gardé le même format plus de 10 ans, à l’époque le micro USB n'existait même pas. (après est-ce qu'ils devraient plutot utiliser de l'USB, c'est un autre débat).

                • [^] # Re: Gitlab recommend at least 1Gb ram

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

                  Eux aussi (surtout eux en fait) ils doivent faire des économies de d'espace et d'argent

                  Comme je le disais, les autres constructeurs y arrivent très bien. Notamment pour la batterie amovible. Quant au connecteur, c'est plutôt, je pense, de l'obsolescence par incompatibilité pour une histoire de gros sous et de brevets, rendant obsolète plutôt les accessoires que le téléphone lui-même. Je ne suis pas sûr que sur certains périphériques, l'adaptateur puisse être utilisé (place physique, maintien stable de l'appareil, notamment dans les voitures, etc.)

                  Côté argent, c'est vrai que leur situation est vraiment précaire. Plus grosse capitalisation boursière, ils ont aussi la plus grosse réserve de cash.

                  Ils ont quand même gardé le même format plus de 10 ans

                  Faux (source). C'est à partir de 2003 que le connecteur 30 broches est arrivé sur des iPod de 3e génération. Avant c'était du firewire. Ça fait donc moins de 10 ans.

                  (après est-ce qu'ils devraient plutot utiliser de l'USB, c'est un autre débat)

                  Ben non, il n'est pas réversible (ce qui est, avouons-le franchement, une véritable révolution).

                  • [^] # Re: Gitlab recommend at least 1Gb ram

                    Posté par . Évalué à  3 .

                    Faux (source). C'est à partir de 2003 que le connecteur 30 broches est arrivé sur des iPod de 3e génération. Avant c'était du firewire. Ça fait donc moins de 10 ans.

                    Ça fait 9 ans c'est tout de même pas mal je trouve (moi qui n'aime pas Apple).

                    Ben non, il n'est pas réversible

                    C'est à dire ?

                    Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                    • [^] # Re: Gitlab recommend at least 1Gb ram

                      Posté par . Évalué à  8 .

                      Le connecteur est dans le groupe cyclique C_2. (on peut le tourner de 180° et ça marche toujours) C'est deux fois mieux qu'un connecteur usb, mais toujours infiniment moins bien qu'un connecteur coaxial.

                      Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

                    • [^] # Re: Gitlab recommend at least 1Gb ram

                      Posté par . Évalué à  9 . Dernière modification : le 01/11/12 à 17:16

                      Ben non, il n'est pas réversible

                      C'est à dire ?

                      C'est à dire que tu peux le brancher dans les 2 sens, ce que ne permet pas l'USB (qui a un détrompeur).
                      Et il faut bien admettre que c'est pratique. Qui n'a jamais râlé contre l'USB et ses 3 sens (" pas dans ce sens-ci… ni dans celui-là… Ah ben le premier était le bon, en fait ! ") ?

                  • [^] # Re: Gitlab recommend at least 1Gb ram

                    Posté par . Évalué à  -7 .

                    Faux (source). C'est à partir de 2003 que le connecteur 30 broches est arrivé sur des iPod de 3e génération. Avant c'était du firewire. Ça fait donc moins de 10 ans.

                    Super, et la concurrence a change combien de fois de connectique entre temps?
                    Vu le nombre de chargeurs divers et varies qui trainent dans mes tiroirs, je dirais une fois tous les 2 a 3 ans au mieux, soit environ 4 a 5 changements

                    (après est-ce qu'ils devraient plutot utiliser de l'USB, c'est un autre débat)
                    Ben non, il n'est pas réversible (ce qui est, avouons-le franchement, une véritable révolution).

                    Deja explique ici meme: trouve le moyen de faire passer tout ce que fait passer le dock d'apple (audio in/out, video, controle a distance et j'en oublie probablement), sans avoir besoin d'un CPU dedie juste pour faire hote USB avec un protocole dédie, et on en reparle.

                    Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                    • [^] # Re: Gitlab recommend at least 1Gb ram

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

                      la connectique a changé 3 fois en 16 ans sur mes telephone nokia, avec à chaque fois des adaptateurs fournis avec les téléphones gerants toutes les anciennes connectiques.

              • [^] # Re: Gitlab recommend at least 1Gb ram

                Posté par . Évalué à  1 .

                Alors que chez Apple, plus de batterie => poubelle et anciens câbles => poubelle.

                Je veux bien venir chercher le matériel que tu jettes pour un défaut de batterie et tes anciens câble ;)

              • [^] # Re: Gitlab recommend at least 1Gb ram

                Posté par . Évalué à  -5 .

                Alors que chez Apple, plus de batterie => poubelle et anciens câbles => poubelle.

                Pour les cables, tu pousses un peu quand meme. Ya qq dizaines de millions d'imachins avec l'ancien dock, les gens les gardent.

                Pour la batterie, la question est combien de temps la batterie tient elle? Mon ipod video a rendu l'ame apres 6 ans de loyaux services, et c'est pas la batterie qui m'a lache mais le disque dur (je suis deja surpris qu'il ait dure aussi longtemps vu ce qu'il a prit).
                Le laptop de madame, 2 ans au compteur, tiens ses 6 heures sur batteries, ce qui est pas si loin de 7 initialement annoncee, apres plus d'une centaine de cycles.

                Les autres constructeurs ont démontré que l'on pouvait faire aussi bien, voire mieux, que les produits de la pomme, avec une batterie amovible, un connecteur standard, etc.

                Ben voyons. Les autres constructeurs qui changent leur format de batterie tous les 6 mois, arretant de produire l'ancien qui donc double ou triple de prix d'un coup?
                Les memes qui changeaient tellement souvent de connectique pour les chargeurs qu'il a fallu pondre une loi au niveau europeen pour les forcer a arreter?

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

        • [^] # Re: Gitlab recommend at least 1Gb ram

          Posté par . Évalué à  4 .

          Je suis développeur, pas sysadmin et justement avec mon architecture de cluster à 2 node, si j'attribue 1Go d'un coté, je doit conserver 1Go de libre de l'autre coté, soit un cout de 2Go.

          De plus le "At least" me fait peur…
          Mon serveur svn actuel dispose de 64mo de ram pour info…

          Mais sinon, oui on a pleins de ram/pétrole/uranium/espace disque/whatever alors pourquoi se priver ?

    • [^] # Re: Gitlab recommend at least 1Gb ram

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

      Pour info, on peut faire tourner une instance de gitlab sur une Raspberry Pi avec 512Mo de RAM. Un collègue a testé et ça tournait très bien.

      Sinon, Ruby est plutôt gourmand en RAM et Rails est une grosse base de code. Actuellement, les serveurs applicatifs fonctionnent avec plusieurs processus et comme Ruby n'est pas encore Copy on write friendly, ça peut vite faire une taille importante. Ruby 2.0 devrait justement régler ce problème (ou en tout cas, limiter son effet).

    • [^] # Re: Gitlab recommend at least 1Gb ram

      Posté par . Évalué à  7 .

      Si tu cherches une alternative plus légère en terme de ressources, il y a RhodeCode.
      Certes, c'est un poil moins joli, mais en plus de Git, ça gère également Mercurial.

      PS: pour l'avoir testé, ça tourne sur un Raspberry PI (sans le Full Text Search pour être honnête)
      PPS: si on était vendredi, j'aurais également signalé que RhodeCode est en Pylons. ;)

  • # Support Fusionforge Git

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

    Git est aussi supporté en standard par la forge logicielle Fusionforge.
    J'en profite pour signaler la sortie de la version 5.2 de fusionforge et la migration svn -> git du repository de sources de fusionforge.

  • # git init --bare

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

    Une petite astuce pour ceux qui chercheraient un moyen rapide et simple de se créer un répo en dehors de github et qui n'ont pas envie de passer 3 plombes a installer du gitlab:

    git init --bare et vous avez un répo

    Vous pouvez y accéder en le présentant a git comme un path unix ou un chemin ssh.

    En espérant que ce sera utile a d'autres.

    • [^] # Re: git init --bare

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

      Oh my god !!! T'es en train de dire qu'avec une gestion de versions distribuée, on peut soit-même être serveur des versions ????
      Perso, je trouve que c'est bien de le rappeler de temps en temps parce qu'en voyant la popularité croissante de GitHub, je me demandais si je n'avais pas rêvé quand j'avais lu décentralisé ;)

    • [^] # Re: git init --bare

      Posté par . Évalué à  5 . Dernière modification : le 31/10/12 à 10:16

      Plutôt que de cloner ton dépôt juste pour le partager, tu peux directement partager un dépôt non bare
      avec git daemon ou avec mercurial: hg serve.

      Mais je vais préparer une petite dépêche pour présenter un produit qui fait la même chose en 2 clics avec une gestion des ACL derrière http(s) et permet aussi de partager ses dépôts svn, s'administre avec un navigateur Web et permet de browser les source en ligne à distance:

      SCM MANAGER

      avec ses screenshots.

      • [^] # Re: git init --bare

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

        Tu me mets l'eau à la bouche ! As-tu déjà utilisé gitolite (git administré… avec git) ? Ça donnerait un point de comparaison.

        • [^] # Re: git init --bare

          Posté par . Évalué à  1 .

          Non, on l'avait éliminé assez tôt car il ne se déployait pas simplement sous Windows je crois.
          Là il s'agit d'une simple appli Java qui se déploie en standalone avec un serveur embarqué ou distribuée comme un war à installer sur un Tomcat.

          A l'époque même le git daemeon de mSysGit partait en carafe.
          Il y avait un deadlock et le dev disait qu'il ne s'y connaissait pas assez en prog parallèle sous Windows pour corriger le bug.

          Le dev est en plus très sympa et très réactif. Tu n'a qu'à aller voir l'activité sur ce projet.

          • [^] # Re: git init --bare

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

            Uh ? Ton cas d'utilisation est de partager le dépôt directement depuis la station de travail ⁈ Parce que sinon, un serveur linux, même virtualisé, ça ne me semble pas être une dépendance difficile à satisfaire.

            • [^] # Re: git init --bare

              Posté par . Évalué à  2 .

              Non on a un workflow centralisé classique. Mais on interdit pas des développeurs de collaborer directement, en attendant que le dépôt central soit créé par exemple ou parce qu'ils sont hors du réseau d'entreprise.

              Ici on a besoin de pouvoir partager son dépôt rapidement et ca le fait.
              Je ne dis pas que le git daemon ne fait pas l'affaire aujourd'hui mais à l'époque non.

              Scm Manager couvre les 2 besoins justement.
              Et en plus il est en full Java ce qui nous convient bien pour prêter main forte, s'adapte à notre archi.
              D'ailleurs un de nos dev a posté le plugin d'intégration crowd.

    • [^] # Re: git init --bare

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

      Une autre astuce consiste à utiliser fossil qui est beaucoup plus simple et plus facile à decentraliser.

      Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

      • [^] # Re: git init --bare

        Posté par . Évalué à  4 .

        Sauf que ca intègre un nouvel outil de gestion de version et qu'on ne sait pas bien s'il est à la hauteur de Git ou Hg.

        • [^] # Re: git init --bare

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

          Je l'ai testé et adopté pour remplacer git il y a bientôt 2 ans pour mes projets persos, car je perdais beaucoup de temps avec la gestion d'un ensemble git+bugtracker+site. Pour la partie gestion de version, tout ce que je peux dire, c'est que ça juste marche alors qu'avec git je me prenais régulièrement la tête avant de faire "un tant pis je commit de la merde" en écumant de rage.

          Par contre, fossil ne permets pas de réécrire l'histoire, ce que les fans de git considèrent comme une friture tueuse.

          Newton Adventure est sur Lumière Verte : http://steamcommunity.com/sharedfiles/filedetails/?id=187107465

          • [^] # Re: git init --bare

            Posté par . Évalué à  2 .

            D'après ce que j'en lis ici
            http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
            http://better-scm.shlomifish.org/comparison/comparison.html

            il ne supporte pas les submodules qui est une feature capitale pour des devs un peu conséquent avec de l'édition de lien statique, ni les checkout partiels (et ls branches locales ?),ne proposa pas de stratégie de merge automatiques
            et sa gestion des changesets ne semble pas supporter le groupage de commit pour faire du cherry picking.

            Sinon dans la même veine des DVCS qui embarquent un bugtracker tu as aussi Veracity:
            http://linuxfr.org/news/veracity-un-nouveau-gestionnaire-de-versions-d%C3%A9centralis%C3%A9

            Pour coder seul, ça peut être sympa mais je me demande comment ca passe à l'échelle pour une équipe.

            D'ailleurs sur le principe même du bugtracker distribué j'ai des doutes. Le fait de centraliser les demandes ca évite que 2 gugusses prennent en charge la même correction en même temps ou créent un même ticket dans leur coin le résolvent.

            • [^] # Re: git init --bare

              Posté par . Évalué à  2 .

              D'ailleurs sur le principe même du bugtracker distribué j'ai des doutes. Le fait de centraliser les demandes ca évite que 2 gugusses prennent en charge la même correction en même temps ou créent un même ticket dans leur coin le résolvent.

              Je dirais que si c'est 'libre', chacun fait ce qui lui plait.

              Sinon les chefs de projets sont faits pour ca.

              • [^] # Re: git init --bare

                Posté par . Évalué à  2 .

                Certes mais le chef de projet n'est pas derrière les devs s'ils n'utilisent pas le système comme ils le devraient.
                Par exemple, en oubliant d'interroger le bugtracker de référence avant de créer un ticket et de le pusher. Et même là le schéma de concurrence optimiste ne préviendra pas des doublons.Ca me parait contre productif.

                L'autre avantage que je vois à la forge centralisée comme moyen de communication et de permettre de se coordonner lorsqu'on doit modifier un fichier non mergeable du style artwork vu qu'on n'a plus de lock pessimiste avec un DVCS.

                • [^] # Re: git init --bare

                  Posté par . Évalué à  3 .

                  Par exemple, en oubliant d'interroger le bugtracker de référence avant de créer un ticket et de le pusher. Et même là le schéma de concurrence optimiste ne préviendra pas des doublons.

                  Et il font quoi les bug trackers actuels ? Ils évitent les doublons ? Comment ? Généralement il permettent surtout de créer des liens entre les tickets (l'un est le même que l'autre, l'un dépend de l'autre, etc).

                  Généralement les dev mangent un gros merge ou 2 puis apprennent à se servir de leur outils.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: git init --bare

                    Posté par . Évalué à  3 .

                    Bon argument en effet.
                    Merger un ticket, ca revient à le lier.

                    Sachant que le coté distribué pourrait permettre de réorienter un ticket upstream avec un autre projet, ca pourrait avoir un intérêt.

                • [^] # Re: git init --bare

                  Posté par . Évalué à  3 .

                  Certes mais le chef de projet n'est pas derrière les devs s'ils n'utilisent pas le système comme ils le devraient.

                  Si ils n'utilisent as le systeme comme il le devrait, tu leur signales gentiment que leur perfomance annuelle va en patir salement. Parce que 1:c'est un point facile a verifier 2:c'est un VRAI point de performance, pas un truc esoterique a l'evaluation aleatoire genre 'contribue a l'entreprise'.
                  C'est bien un des roles de chef de projet d'etre derriere ses devs justement. Parce que le jour ou deux gugusse ont bosse sur le meme truc, bah ca va faire baisser la marge du projet, et donc lui retomber dessus.
                  Le fait que deux personnes bossent sur la meme chose juste parce que un des deux a 'oublie' de verifier ses outils, bah aucun outil ne le resoudra.

  • # Que vaut GitStack ?

    Posté par . Évalué à  1 . Dernière modification : le 31/10/12 à 10:16

    Je suis actuellement pour mon usage personnel sur cvsnt, et le plugin cvs pour Eclipse.
    Au moment de m'interesser a GIT, il y avait pas grand chose pour Windows niveau local, mais cette depeche fait m'y reinteresser. Le plugin Eclipse s'est semble t'il etoffe et offre au moins les meme fonctionalites que celui de CVS (et utiliesr la ligne de commande n'etant pas une option pour moi, ne m'apportant rien pour mon usage, si ce n'est la perte de temps associee a son apprentissage).

    Quels sont les autres serveurs Windows a par GitStack (gratuit)?

    • [^] # Re: Que vaut GitStack ?

      Posté par . Évalué à  3 .

      J'ai répondu plus haut scm manager convient parfaitement sous Windows pour partager son dépôt.
      Il est complémentaire d'EGit qui ne permet pas de partager son dépôt et il s'intègre très bien sur un serveur de prod.
      Nous l'utilisons en conjonction avec le reste de la suite Atlassian à la place de FishEye et de son futur Stash.
      Il s'intègre bien a Crowd.

      EGit est aujourd'hui utilisable mais il a encore quelques lacunes parmi lesquelles certaines assez gênantes, notamment:
      - Il ne permet pas de suivre un merge entre 2 branches si des fichiers ont été renommés. (merge rename tracking). Assez génant quand on vend Git comme supérieur à SVN pour les branches. Pas de refactoring sans la ligne de commande
      - Le stash pop t'écrase tes fichiers sans préavis y compris ceux que tu aurais modifié entre temps. A toi de faire attention a comparer ton index et le commit précédent avant le commit
      - L'outil de merge n'est pas encore à la hauteur de ce qui se faisait avec Clearcase par exemple. Il te présente le fichier brut de fonderie à éditer avec les balises ou te permet juste de passer tes modifs de la source vers la cible.
      Celui de clearcase te permettait de choisir le contenu que tu voulait (la cible, la source ou l'antécédant) et sa stratégie de merge 3 contributeurs te mâchait le travail lorsqu'un ligne n'était modifiée que d'un coté.
      … et quelques autres irritants.

      Mais globalement il est maintenant stable et fonctionnel.

      MSySGit et maintenant bien stabilisé aussi et en plus ne nécessite pas de droits d'admin sur le poste pour être installé.

      Bref le sempiternel "Git ne fonctionne pas sous Windows" n'est plus d'actualité.

    • [^] # Re: Que vaut GitStack ?

      Posté par . Évalué à  2 .

      Je n'ai pas bien compris comment se positionne GitStack en terme de licence.

      Il semble qu'il soit disponible sous GPLv3 mais qu'on ne puisse pas l'utiliser librement
      http://gitstack.com/pricing/

      Je sais bien qu'un logiciel libre n'est pas gratuit mais ça ne semble pas clair.

      • [^] # Re: Que vaut GitStack ?

        Posté par . Évalué à  4 .

        Je sais bien qu'un logiciel libre n'est pas gratuit mais ça ne semble pas clair.

        Bah comme d'hab, t'as le noyau open source qui sert pas a grand chose tout seul, puis t'as le sucre autour qui le rend utile qui lui est payant.
        Ici le sucre est gratos dans le cas d'une utilisation perso (2 utilisateurs).

      • [^] # Re: Que vaut GitStack ?

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

        C'est assez étonnant. Le logiciel est bien open source, et on peut voir qu'il y a bien du code pour verifier les licenses achetées et verifier que le nombre d'utilisateurs correspond au nombre de licenses :
        https://github.com/smart-mobile-software/gitstack/blob/master/app/gitstack/models.py#L289

        Le code de LicenceChecker par contre ne semble pas inclut.

        Mais il suffirait de commenter ces quelques lignes pour ne plus etre embeté par ces histoires de licenses.

  • # Et la gestion de sous-modules ?

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

    Est-ce que ça évolue de ce côté ?

    J'ai toujours un moment d'hésitation quand je fait une update du supermodule. Je dois me remémorer comment vont être tirés les sous modules, comment les modifs que j'y ai apporté vont êtres gérées…

    Bref, je ne me sens toujours pas à l'aise avec ce système pourtant très utile.

Suivre le flux des commentaires

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