• # SCM propriétaire

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

    Remarque sans rapport avec l'intrusion en question :

    Audit the SVN and Perforce repositories to:

    Ça m'aura permis de découvrir que le projet FreeBSD utilise un outil de gestion de versions propriétaire (Perforce). Cf http://www.freebsd.org/doc/en/articles/p4-primer/index.html « The FreeBSD project uses the Perforce version control system to manage experimental projects that are not ready for the main CVS repository. »

    • [^] # Re: SCM propriétaire

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

      the client software for interacting with the server is freely available from Perforce.

      freely = gratuitement, si j'ai bien suivi. À quand LibreBSD pour enlever toute confusion ? (le terme Libre Software étant repris dans l'acronyme FLOSS et compréhensible par les anglophones connaissant l'espagnol ou le français…).

    • [^] # Re: SCM propriétaire

      Posté par . Évalué à  4 .

      L'histoire des VCS de FreeBSD est assez intéressante et surprenante à la fois. Il y a un très bref aperçu ici: http://wiki.freebsd.org/VCSWhy

      Je profite de la digression pour demander des retours d'expérience sur l'utilisation d'un dépot CVS avec un outil local ne tuant pas la productivité. Je suis à la recherche d'une solution performante pour retrouver la productivité que l'on peut avoir avec les outils modernes.

      • [^] # Re: SCM propriétaire

        Posté par (page perso) . Évalué à  1 . Dernière modification : le 18/11/12 à 01:45

        demander des retours d'expérience sur l'utilisation d'un dépot CVS

        ça dépend, au siècle dernier ou dans les dix dernières années ?

        avec un outil local ne tuant pas la productivité

        eclipse ?

        à la recherche d'une solution performante pour retrouver la productivité que l'on peut avoir avec les outils modernes.

        bin redmine gère git et c'est en Ruby, sinon, ya VHFFS que tu peux aussi installer chez toi, les deux gèrent un truc du siècle dernier comme CVS mais aussi subversion et git (voire mercurial).

        • [^] # Re: SCM propriétaire

          Posté par . Évalué à  4 .

          ça dépend, au siècle dernier ou dans les dix dernières années ?

          M'enfou ;)

          D'après mes tests l'utilisation de DCVS en client forcément n'est pas forcément génial (mais l'avis de quelqu'un qui à un peu poussé le truc serait intéressante). Il reste les outils de patchs management que je n'ai pas encore trop regardé.

          eclipse ?

          Eclipse c'est uniquement le moins pire. Dès que tu as besoin d'empiler des patchs qui touchent au mêmes fichiers, de branches, de revenir dans l'historique c'est la mort.

          bin redmine gère git et c'est en Ruby, sinon, ya VHFFS que tu peux aussi installer chez toi, les deux gèrent un truc du siècle dernier comme CVS mais aussi subversion et git (voire mercurial).

          Tu penses bien que si je pose la question c'est qu'il y a une raison. Et donc me répondre d'utiliser un autre type de dépôt ne m'avance guère ni ne répond à ma question.

          • [^] # Re: SCM propriétaire

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

            Tu penses bien que si je pose la question c'est qu'il y a une raison. Et donc me répondre d'utiliser un autre type de dépôt ne m'avance guère ni ne répond à ma question.

            La petite pique sur CVS était une façon détournée d'indiquer que si svn puis git et mercurial sont désormais disponibles, c'est bien que certaines limites ont été atteintes et que de nouvelles fonctionnalités étaient nécessaires ;-)

            La gestion de code (et ses différentes branches, gestion de merge…) est un vaste sujet, tu pourras trouver quelques articles de Linus, notamment, indiquant son workflow et ce qu'il avait besoin de faire. Concrètement, tu rencontres quelles difficultés, qu'attendrais-tu spécifiquement comme améliorations ?

            • [^] # Re: SCM propriétaire

              Posté par . Évalué à  3 .

              La petite pique sur CVS était une façon détournée d'indiquer que si svn puis git et mercurial sont désormais disponibles, c'est bien que certaines limites ont été atteintes et que de nouvelles fonctionnalités étaient nécessaires ;-)

              Je pensais juste que je traînais ici depuis assez longtemps ici pour que tu m'épargnes cette étape ;) Elle aurait déjà été inutile il y a 10 ans où IIRC j'avais les limites de CVS déjà bien en tête et l'avais même souvent remplacé par un DCVS ou svn…

              Concrètement, tu rencontres quelles difficultés, qu'attendrais-tu spécifiquement comme améliorations ?

              Concrètement on peut oublier toute les problématiques du côté dépôt (archéologie sur la base, branche/tag publique) c'est inévitable et on ne peut que pleurer.

              Par contre j'ai besoin de pouvoir bosser sur plusieurs trucs en parallèles dont le développement et la validation sont assez longs. En gros un patch ou une suite de patch peut traîner quelques jours/semaines avant que je pousse où que j'envois pour review. Bref j'ai vraiment besoin d'avoir un équivalent de branches locales et de pouvoir ensuite facilement pousser mes changesets et me synchroniser avec le dépot.

              Bref l'équivalent d'un git-svn même bien castré serait parfait. J'ai commencé a tester git-cvsimport/git-cvsexport mais pour le moment ça me semble assez bancale. Comment bossent les autres, ou le workflow du projet je m'en fou. Je veux juste pouvoir travailler tranquillement dans mon coin sans produire de la merde et perdre 10x plus de temps qu'avec un DCVS pour faire la même chose. On peut voir l'étape de pousser sur le CVS comme pousser sur un repo externe. Si ils perdent toutes les metadatas ou autre je m'en fou.

              • [^] # Re: SCM propriétaire

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

                Je pensais juste que je traînais ici depuis assez longtemps ici pour que tu m'épargnes cette étape ;)

                oui, comme tu me le dis quasi à chaque fois et, vu que je ne m'en lasse pas, bin je continue :D

                Vu que LinuxFr.org est un site ouvert à tous, je ne vois pas de souci à expliciter certaines private jokes, ce qui permet de préciser la demande au passage :)

                • [^] # Re: SCM propriétaire

                  Posté par . Évalué à  4 . Dernière modification : le 19/11/12 à 09:03

                  J'avoue sans problème essayer de faire des réponses adaptées et utiles à l’interlocuteur (dans le doute j'ai tendance à considérer les gens comme des grandes personnes). Dans le cas présent, sauf à avoir un fort soupçon que le type à raté l'évolution des VCS depuis 2000 je me dirais que si il demande comment rendre CVS moins pénible en local lui dire que d'autres types de repository existent, et qu'il n'a qu'à changer de repo ne va pas l'aider des masses.

                  J'avoue sans problème non plus qu'une meilleur formulation de la question aurait été: Il faut que j'utilise CVS, c'est quoi le meilleur client CVS qui permet d'avoir un historique local, des branches locales et une synchronisation bidirectionnelle ? Un git-svn like quoi.

      • [^] # Re: SCM propriétaire

        Posté par . Évalué à  2 .

        je connais pas cvs mais en demandant à un pote (Google), j'ai trouvé çà :
        http://stackoverflow.com/questions/584522/how-to-export-revision-history-from-mercurial-or-git-to-cvs/586225#586225

        je sais pas si ça répond à ton besoin…

        • [^] # Re: SCM propriétaire

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

          git cvsimport est comme osn nom dl'indique tout juste bon à importer un repo CVS sous git, c'est trés trés loin de ce que tu peux faire avec git-svn qui lui te permet de garder ton dépot local git synchronisé avec un dépot SVN sans trop de peine.
          Bref, ça dépanne mais c'est loin vraiment utilisable.

          Ceci dit, j'aurai envie de dire qu'en 2012 celui qui tourne encore sous CVS merite un coup de pied au cul, mais ce n'est que mon avis…. :D

          • [^] # Re: SCM propriétaire

            Posté par . Évalué à  2 .

            Pour le lien je l'avais déjà trouvé. J'ai commencé à expérimenter cette semaine mais pour le moment j'arrive pas à être super convaincu que ca va le faire. D'où l'appel à des gens qui auraient expérimenté en vrai.

            git cvsimport est comme osn nom dl'indique tout juste bon à importer un repo CVS sous git, c'est trés trés loin de ce que tu peux faire avec git-svn qui lui te permet de garder ton dépot local git synchronisé avec un dépot SVN sans trop de peine.

            Normalement tu peux ressortir le tout avec cvsexport. Reste à voir qu'il n'explose pas en vol vu les concepts totalement différent des deux.

            Ceci dit, j'aurai envie de dire qu'en 2012 celui qui tourne encore sous CVS merite un coup de pied au cul, mais ce n'est que mon avis…. :D

            On est entièrement d'accord. Mais ça ne m'avance absolument pas ;)

    • [^] # Re: SCM propriétaire

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

      En fait, il conviendrait de ré-écrire cette phrase à l'imparfait. Perforce était utilisé quand le projet utilisait encore CVS, mais depuis la migration vers SVN, il est pratiquement devenu inutile.

  • # Vive la compil

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

    En lisant le rapport, on voit que les machines touchées faisaient partie du cluster permettant la construction des packages des logiciels tiers (donc hors base).
    On voit aussi que les repo SVN et Perforce ont été audités et que rien n'a été touché.
    Conclusion : Sous BSD, il vaut mieux toujours utiliser les sources via les ports plutôt que les packages :)

    • [^] # Re: Vive la compil

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

      Sous FreeBSD peut-être, mais ne généralisons pas : OpenBSD recommande au contraire l'utilisation des paquets binaires plutôt que de compiler depuis les ports.

      Everyone is encouraged to use the pre-compiled binary packages.

      Source : http://openbsd.org/faq/faq15.html#Ports

      • [^] # Re: Vive la compil

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

        Enfin, cette fois-ci, c'eut été un mauvais conseil !!
        D'ailleurs, j'ai du mal à voir la justification, les avantages de la compilation étant :
        - colle au plus près à l'architecture de la machine (pas de compatibilité avec un truc antédiluvien)
        - permet de passer des options de compilation non utilisées pour les mêmes raisons

        Par contre, c'est pas forcément pour les newbies mais c'est quand même pas la mort à utiliser.

Suivre le flux des commentaires

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