Sortie de GNU CSSC 1.3.0

Posté par . Modéré par Florent Zara.
Tags :
18
8
nov.
2010
GNU
Pendant de nombreuses années, SCCS (Source Code Control System) fut le seul logiciel de gestion de versions disponible sur les systèmes Unix, avant qu'il ne soit supplanté par RCS puis par les gestionnaires de versions modernes comme CVS, ou git. Afin que les utilisateurs d'Unix migrant vers le libre puissent accéder à leur référentiel SCCS, le projet GNU inclut un logiciel astucieusement nommé CSSC (« compatibly stupid source control »), dont la version 1.3.0 est sortie ce lundi.

Cependant, les implémentations de SCCS pouvant être légèrement différentes entre les Unix, et surtout plusieurs hacks ayant circulé pour améliorer ce produit, de nombreux utilisateurs de CSSC doivent modifier ce logiciel afin de retrouver les fonctionnalités de « leur » SCCS d'origine. Jusqu'à présent, modifier le code de CSSC n'était pas évident, et la version 1.3.0 veut justement répondre à ce besoin : elle n'apporte pas de nouvelles fonctionnalités, mais elle a fait l'objet d'un très sérieux toilettage du code grâce à l'utilisation de bibliothèques GNU standards (l'inconvénient étant que GNU CSSC devient moins simple à compiler sur d'anciens systèmes ne disposant pas de ces bibliothèques).

Pour ceux qui se demandent à quoi peut bien servir ce projet, la réponse est derrière le premier lien : de très nombreux logiciels sont stockés au format SCCS, GNU CSSC a pour but de permettre aux développeurs de les récupérer afin qu'ils puissent les intégrer à un système de gestion de versions moderne.
  • # Objectif ?

    Posté par . Évalué à 3.

    > Once retrieved, it is highly recommended to bring the source under the control of more
    > modern source code control systems, such as CVS.

    J'imagine que les gens qui ont encore des données sous ces système doivent être frileux au point de refuser de migrer vers quelque chose de moins antique que CVS ?

    En tout cas, si l'objectif affiché est de sortir des données de SCCS pour le réinjecter dans des VCS plus récents, des systèmes d'export/import suffiraient (pas besoin de savoir faire de lécriture dans SCCS, il suffit de savoir sortir les données).
    • [^] # Re: Objectif ?

      Posté par . Évalué à 4.

      Le problème est que tout ne peut pas être fait en même temps : avoir un outil comme GNU CSSC permet de gérer une migration au libre sans avoir comme prétexte pour ne rien changer pré-requis une migration de tous les logicielssous SCCS. Soyons réalistes, comme beaucoup de logiciels GNU, il s'agit d'un outil créé pour que GNU soit compatible avec les unix propriétaire, mais tout jusqu'au nom de l'application montre que le souhait de ses développeurs est qu'il ne serve qu'à faire des migrations vers un système plus moderne.

      Membre de l'april, et vous ? http://www.april.org/adherer

  • # J'adore

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

    Je trouve excellent le nom choisi par GNU.

    Je n'ai jamais utilisé SCCS, mais je sais qu'il y a au moins un chercheur de l'INRIA qui ne jure que par lui !

    Pour avoir vu un joli troll GPL/BSD dans un autre fil, je trouve ce projet plus intéressant et plus utile que le projet OpenCVS (BSD) dont l'objectif est de réimplanter un serveur CVS alors qu'il en existe un, certes vieillot, mais qui est suffisant pour faire une migration.
    • [^] # Re: J'adore

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

      C'est comme GPG pour PGP…
      • [^] # Re: J'adore

        Posté par . Évalué à 9.

        Certe mais il y a plus d'humour dans « compatibly stupid source control » que dans « GNU Privacy Guard ».

        Pour ma part je dois vraiment être jeune parce que pour moi un vieux gestionnaire de version c'est subversion et un jeune c'est git/mercurial.... Je n'ai jamais touché à CVS qui m'avait était présenté comme ancestral.

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: J'adore

          Posté par . Évalué à 3.

          Pour ma part je dois vraiment être jeune parce que pour moi un vieux gestionnaire de version c'est subversion et un jeune c'est git/mercurial.
          En effet, pourtant j'ai pas encore la trentaine. SVN est top moumoute par rapport a CVS, mais git et mercurial sont radicalement différents, et jeunes comme tu dis. Ca se sent au niveau des outils gravitant autour et de l'intégration avec les IDE.

          Ceux qui t'ont présenté CVS comme ancestral ont bien fait, ils t'ont bien appris.
          • [^] # Re: J'adore

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

            Le problème de git, c'est le client Windows... Pour mes utilisateurs non développeur, TortoiseSVN, c'est du solide !
            • [^] # Re: J'adore

              Posté par . Évalué à 1.

              Tu n'as pas de problème de gens qui font des copier/coller de dossiers et crées des conflits à cause des .svn ?
              • [^] # Re: J'adore

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

                Non, ils en font une utilisation très basique et les 3/4 du temps, c'est juste pour faire un update" pour se synchroniser.
                • [^] # Re: J'adore

                  Posté par . Évalué à 1.

                  Je trouve tout de même ce point bien gênant et je suis bien content que git/mercurial aient un seul dossier technique à la racine.
                • [^] # Re: J'adore

                  Posté par . Évalué à 1.

                  dans tortoiseSVN j'avoue que je cherche encore l'équivalent de cvsDiff ou de "blame", ceci dit j'ai pas trop cherché.

                  "La première sécurité est la liberté"

                  • [^] # Re: J'adore

                    Posté par . Évalué à 2.

                    blame => clic droit sur le fichier -> "tortoiseSVN" -> "blame..."

                    pour avoir un diff, plusieurs possibilités :
                    * clic droit sur le fichier -> tortoiseSVN -> "diff with previous version" (ça ouvre un soft extérieur, chez moi Winmerge) ;
                    * clic droit sur le fichier -> "commit..." -> clic droit -> "show diffrences as unified diff' (ça ouvre une fenêtre en lecture seule, montrant ce que contiendrait le patch);
                    * clic droit sur le fichier -> tortoiseSVN -> "create patch..." (permet d'enregistrer la modif sous forme de patch).
          • [^] # Re: J'adore

            Posté par . Évalué à 3.

            Merci pour la confirmation j'avais un peu l'impression de passer à coté de quelques chose quand je vois ce genre de news et qu'il reste des projets qui utilisent CVS.

            Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

            • [^] # Re: J'adore

              Posté par . Évalué à 3.

              Tu passes a cote de la joie:
              - du versioning fichier par fichier,
              - impossible de copier un fichier sans perdre l'historique.
              - impossible de copier un répertoire,
              - des commits non atomiques (coupure de courant au milieu d'un commit? pas de bol!)
              - non possibilité de voir tout ce qui a été committé exactement ensemble, la vitesse pou les opérations basiques (diff des modifications dans ton wokspace avec la révision a laquelle il se trouve), etc. J'en passe et des meilleures.

              Si tu veux vraiment voir ce que tu manques (ou que tu as 5 min a perdre), voici quelques liens:
              - http://www.pushok.com/soft_svn_vscvs.php
              - http://www.journaldunet.com/developpeur/tutoriel/out/060127-(...)
              - https://secure.wikimedia.org/wikipedia/fr/wiki/Apache_Subver(...)

              Non vraiment il ne faut pas regretter CVS et encore moins les outils qui existaient avant. Les gens qui décident d'utiliser encore SCCS, doivent être maso ou sacrément obtus.



              Maintenant, SVN et git/mercurial/... ont des workflow différents et s'applique a des besoins/situations différentes. Je travaille avec SVN tous les jours et ca marche quand même pas mal. Parfois je me dis bien que tel gestionnaire de version X ou Y a telle fonctionnalité qui me serait bien utile dans une situation précise, mais c'est quand même assez rare. On arrive toujours a se débrouiller.
              • [^] # Re: J'adore

                Posté par . Évalué à 3.

                Parfois je me dis bien que tel gestionnaire de version X ou Y a telle fonctionnalité qui me serait bien utile dans une situation précise, mais c'est quand même assez rare. On arrive toujours a se débrouiller.

                Un truc qui manque a SVN, c'est quand meme des bons outils de merging & branching. Parce que lorsque tu travailles sur des branches, c'est quand meme la grosse merde pour faire marcher tout ca correctement (meme si ca s'est ameliore depuis un moment).

                Sinon l'avantage de Git/Mercurial, c'est qu'il y a des passerelles entre eux (et avec SVN aussi) et donc tu peux facilement contribuer facilement en utilisant l'outil que tu veux (meme si ca reste encore assez jeune et il y a des bugs encore un peu partout). Mon projet migre bientot sous Git, mais pas question que je l'utilise (en particulier sous Windows, c'est completement a chier, lent, mais lent! avec des mainteneurs qui n'utilisent pas le systeme et menacent de tout laisser tomber des que les gens ne sont pas d'accord avec eux - genre extremiste du LL, ironique quand tu fais du dev pour windows).
                • [^] # Re: J'adore

                  Posté par . Évalué à 1.

                  « tu peux facilement contribuer facilement »

                  Comme quoi c'est vraiment facile.

                  Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

                • [^] # Re: J'adore

                  Posté par . Évalué à 2.

                  Un truc qui manque a SVN, c'est quand même des bons outils de merging & branching. Parce que lorsque tu travailles sur des branches, c'est quand même la grosse merde pour faire marcher tout ca correctement (même si ca s'est amélioré depuis un moment).
                  J'ai toujours pas compris le besoin de faire un truc a la Svnmerge.py avec des méta données qui viennent te pourrir tous les fichiers avec des métadonnées alors que le fichier lui même n'a jamais changé. C'est tout simplement incompréhensible.

                  L'avantage que je vois a Git par rapport a Mercurial est l'intégration avec SVN. Le seul probleme est que je l'ai utilisé sur notre projet mastondontesque sur windows (bouh! Heureusement cygwin est la!) et perl s'est lamentablement vautré comme une loutre bourrée un soir de Saint Sylvestre. Sacrées loutres!

                  avec des mainteneurs qui n'utilisent pas le systeme et menacent de tout laisser tomber des que les gens ne sont pas d'accord avec eux - genre extremiste du LL, ironique quand tu fais du dev pour windows).
                  LOL. Certaines personnes sont marrantes quand même. Je leur suis tout de même reconnaissant pour le boulot réalisé :)
                  • [^] # Re: J'adore

                    Posté par . Évalué à 4.

                    LOL. Certaines personnes sont marrantes quand même.

                    Oue, plutot que marrant, je dirais que c'est juste un douchebag.

                    > The least painful and most compatible/supported approach though would
                    > be to use .msi installer.

                    In your dreams.

                    --

                    I am totally opposed to making special changes just for Windows. You might be fine
                    with it, but my main platform is not Windows, and I am _not_ prepared to pay even
                    more tribute to Redmond's silly conventions.

                    --

                    Well, let me tell you a story. Every couple of years something reignites
                    my interest in cooperating with some Windows developers. I try to work
                    with them, try not to outpace them.

                    And guess what? I still find Windows developers to be 99% lazy bastards
                    who do not use the thing between their ears. And they'd rather stick to
                    their slow, bug- and virus-ridden environment, than switch to a saner
                    platform. They pretend to have rational reasons for it, but they don't.

                    So far, I have to say, I am underwhelmed by the enthusiasm at which
                    _Windows_ developers participate in msysGit.

                    It comes as _no_ surprise to me that the innovations in Windows invariably
                    are stolen from other platforms, that they mostly exstinguished.


                    Les principaux mainteneurs git laissent le sale boulot du support windows a des types comme ca, et apres on s'etonne que le support soit tout pourri...
        • [^] # Re: J'adore

          Posté par . Évalué à 1.

          pareil :)
    • [^] # Re: J'adore

      Posté par . Évalué à 6.

      je trouve ce projet plus intéressant et plus utile que le projet OpenCVS (BSD) dont l'objectif est de réimplanter un serveur CVS alors qu'il en existe un, certes vieillot, mais qui est suffisant pour faire une migration.

      Ben justement openCVS n'est pas fait pour les gens qui veulent migrer, mais pour ceux qui veulent continuer à utiliser un "CVS" parce que ça leur suffit, mais avec un serveur qui n'est pas rempli de failles comme celui de chez GNU.
  • # Sauvegarde locale

    Posté par . Évalué à 1.

    SCCS ou RCS restent des outils très pratique pour sauvegarder localement les modifications apportées à des fichiers. De ce point de vue, ces outils sont beaucoup plus pratiques que les systèmes distribués tels que CVS ou SVN.

    De plus, SCCS et RCS sont particulièrement bien intégrés à emacs.

    Par exemple, la commande vc-next-action (C-x v v) permet d'ajouter n'importe quel fichier (par défaut en RCS). La même commande permet ensuite de sauvegarder des versions dans le RCS.

    Cela ne demande aucune configuration contrairement à CVS et SVN.
    • [^] # Re: Sauvegarde locale

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

      SCCS ou RCS restent des outils très pratique pour sauvegarder localement les modifications apportées à des fichiers. De ce point de vue, ces outils sont beaucoup plus pratiques que les systèmes distribués tels que CVS ou SVN.

      Git fait ça très bien, en plus tu peux exporter facilement le dépôt si tu en as besoin.

      « 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: Sauvegarde locale

        Posté par . Évalué à 2.

        Je ne connais pas git mais après une lecture rapide de la doc, il me semble en effet permettre la gestion locale contrairement à CVS et SVN qui sont plutôt basés sur des concepts client-serveurs avec un unique dépôt sur le serveur et de multiples copies de travail sur les clients.

        Il me semble quand même y avoir une différence importante entre GIT et SCCS/RSC.

        GIT gère un dossier et son contenu de façon récursive. Toutes les informations de version se trouvent dans le dossier '.git' créé à la racine de l'arborescence par la commande 'git init'. Dans RSC comme dans SCCS, chaque fichier est géré indépendamment. L'historique d'un fichier 'toto.c' se trouve dans le fichier local 'RCS/toto.c,v' dans le même dossier que le fichier toto.c

        Les 2 systèmes ont leurs avantages et leurs inconvénients. GIT permet de gérer des projets avec toute la complexité associée (branches, ...) alors que SCCS/RSC reste simple en gérant les fichiers indépendamment les uns des autres.

        Par exemple, SCCS ou RSC me semble beaucoup plus adapté que GIT pour sauver les versions de mes fichiers ~/.emacs et ~/.bashrc. Il est probablement possible de créer une arborescence git dans $HOME mais vu sa nature récursive, je trouverai cela un peu "dangereux".
        • [^] # Re: Sauvegarde locale

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

          Par exemple, SCCS ou RSC me semble beaucoup plus adapté que GIT pour sauver les versions de mes fichiers ~/.emacs et ~/.bashrc. Il est probablement possible de créer une arborescence git dans $HOME mais vu sa nature récursive, je trouverai cela un peu "dangereux".

          Git ne va aller chercher que les fichiers qui ont été ajouté avec git add, donc, je ne crois pas que ça pause problème (mais je ne le garantirais pas).

          « 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: Sauvegarde locale

            Posté par . Évalué à 2.

            D'après ce que je connais sur git, tu as tout a fait raison.
            par défaut git ignore tous les fichiers présents jusqu'à ce que tu fasse un git add avec leur nom.
            • [^] # Re: Sauvegarde locale

              Posté par . Évalué à 2.

              Ou sur le dossier qui les contient.

              Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Sauvegarde locale

          Posté par . Évalué à 1.

          Par exemple, SCCS ou RSC me semble beaucoup plus adapté que GIT pour sauver les versions de mes fichiers ~/.emacs et ~/.bashrc. Il est probablement possible de créer une arborescence git dans $HOME mais vu sa nature récursive, je trouverai cela un peu "dangereux".

          Oui, donc autant dire que SCCS / RCS sont des jouets antédiluviens par rapport à Git ou Mercurial.
          (je dois dire que j'ai dû me frotter les yeux en lisant la dépêche ; un truc encore plus vieux que RCS et qui soit encore utilisé, j'imaginais pas que ça puisse exister)
    • [^] # Re: Sauvegarde locale

      Posté par . Évalué à 1.

      1) SVN ou CVS ne sont pas des systèmes de gestion distribuée, mais complètement centralisée
      2) SVN, CVS, Git, et Mercurial sont très bien intégrés à GNU/Emacs, merci
      3) RCS, SCCS, CVS, SVN sont dépassés
      • [^] # Re: Sauvegarde locale

        Posté par . Évalué à 3.

        Euh tu va un peu vite en besogne pour SVN. Je ne serais pas celui qui le défend bec et ongle, mais il permet des choses que git et mercurial ne permettent pas. Voir pour un retour d'expérience:
        http://live.gnome.org/GitMigration

        Par exemple un sparse checkout: les traducteurs ouzbeks de logiciels GNOME doivent maintenant télécharger tous le logiciel au lieu de simplement faire un checkout sur le répertoire des traductions avec un debit internet famélique. Pareil pour ceux qui ne travaillent que sur le répertoire site/ pourquoi devraient ils prendre le code source aussi?

        Lors d'un merge, si les heuristiques de Git ne marchent pas dans ton cas, alors pas de bol pour toi. Par exemple: nous avons réorganisé le code pour le rendre plus modulaire (déplacement de repertoires , de fichiers, etc.). Quand j'ai essaye Git pour faire un merge de fichiers ajoute a un ancien répertoire, Git me l'a recrée dans un répertoire qui n'existe plus dans la branche ou je fais le merge! Mercurial doit mieux gérer ce cas la je pense puisqu'il gère individuellement les fichiers. Par contre cette faculté de Git lui permet de se rappeler toutes les lignes de codes, même si le code a été déplacé dans un autre fichier.


        Enfin, le plus gros argument, c'est que pour une grosse équipe de développement, passer de SVN a Git/Mercurial implique un grand changement dans la façon de travailler, parce que l'outil ne fait pas tout et que les humains sont plus essentiels que les outils. Si les gens sont plus a l'aise avec SVN parce que SVN est beaucoup plus simple a comprendre, alors peut être que les outils plus avancés ont manqué quelque chose? Un exemple a la con serait Google Wave qui devait rendre l'email, l'IM, les wikis et les forums obsolètes, pourtant toutes ces choses sont encore la et pas encore dépassées (J'avais prévenu que c'était un exemple a la con).


        Bien sur je ne dénie pas les avantages qu'apporte Git et Mercurial, mais tout n'est pas rose non plus et SVN est encore la pour un bon bout de temps. Donc SVN n'est pas si dépassé ni même prêt de disparaître.

Suivre le flux des commentaires

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