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.
Aller plus loin
- Site web du projet (13 clics)
- GNU CSSC sur savanah (3 clics)
- Liste de discussion des utilisateurs (2 clics)
- DLFP : Quel est votre logiciel de gestion de versions favori ? (4 clics)
# Objectif ?
Posté par mickabouille . Évalué à 3.
> 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 Denis Dordoigne . Évalué à 4.
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
# J'adore
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: J'adore
Posté par barmic . Évalué à 9.
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.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'adore
Posté par djano . Évalué à 3.
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 Sytoka Modon (site web personnel) . Évalué à 5.
[^] # Re: J'adore
Posté par Vincent . Évalué à 1.
[^] # Re: J'adore
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: J'adore
Posté par Vincent . Évalué à 1.
[^] # Re: J'adore
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: J'adore
Posté par windu.2b . Évalué à 2.
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 barmic . Évalué à 3.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'adore
Posté par djano . Évalué à 3.
- 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 Littleboy . Évalué à 3.
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 barmic . Évalué à 1.
Comme quoi c'est vraiment facile.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: J'adore
Posté par djano . Évalué à 2.
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 Littleboy . Évalué à 4.
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 cosmocat . Évalué à 1.
[^] # Re: J'adore
Posté par Psychofox (Mastodon) . Évalué à 6.
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.
[^] # Re: J'adore
Posté par Sytoka Modon (site web personnel) . Évalué à -1.
# Sauvegarde locale
Posté par SChauveau . Évalué à 1.
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 claudex . Évalué à 4.
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 SChauveau . Évalué à 2.
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 claudex . Évalué à 4.
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 djano . Évalué à 2.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sauvegarde locale
Posté par Antoine . Évalué à 1.
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 Mathieu Segaud . Évalué à 1.
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 djano . Évalué à 3.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.