CVS et ClearCase sont deux systemes de version pour developper des projets informatiques.  
(creer des branchs, des views, faire des check-in/check-out etc...)
 
j utilise ClearCase en stage, mais je voulais savoir si y avait beaucoup de difference avec CVS ??

ClearCase suxor
 
CVS roxor  
 
 

pkoi
 
qu est ce qu on peut faire avec CVS exactement ??
 
avec clear case, tu peux:
 
creer des Views en paramettrant ton ConfigSpec pour dire quel branches et Versions/label et fichiers tu veux voir.  
 
tu peux creer sous unix/windows, ou bien juste les importer vers windows.
 
tu peux "merger" les fichiers, avec un assistant.
 
tu peux poser des "label" sur un groupe de fichier different avec des version differentes.
 
y a surement d autre truc encore...mais ca vient en tete la

ahhhh lalala
 
on a eu le même truc au boulot
 
les plus vieux ont voté ClearCase, les plus jeunes CVS
 
finalement c'est cvs qui est passé le 1er pour se prouver, mais selon moi ca va rester

cvs
et j'ai envie d'essayer subversion un de ces 4.
 
clearcase c'est un truc tout laid et propriétaire non?  

 
clearcase c IBM

 
Au niveau du suivi des versions, les fonctionnalités sont les mêmes, même si le vocabulaire change. On parle pas de label, mais de tag par exemple.
 
La différence se situe principalement sur la gestion des accès concurents. Sur clear case, c'est un mécanisme de lock. Le check-in permet au développeur de prendre la main sur une ressource, le check-out va la rendre et la mettre à jour au niveau du référentiel permetant aux autres utilisateurs de se mettre à jour.
 
CVS ne fonctionne pas comme ça. Tu fait un "cvs co nomdumodule". Cela permet de faire un check-out d'un module (module=ensemble de ressources formant une application). A partir de là, tu fait toutes les modifications que tu veux dans tous les fichiers que tu veux. Si quelqu'un met à jour le référentiel, tu fait un "cvs update nomdumodule". Cela va interroger le serveur pour faire un diff entre la version du serveur et ce que tu as. Et les modifications rendues disponibles sur le serveur sont insérées dans la version sur laquelle tu travailles. La granularité est de l'ordre de  la ligne. Tu travailles sur une fonction toto d'une classe, un collègue modifie tutu et la livre. Le update va insérer la nouvelle version de tutu dans ta version de travail sans casser ta fonction toto.
 
Bien sur, il reste le cas où vous avez modifié la même ligne de code. Dans ce cas, CVS demande à l'utilisateur quelle version il doit garder. C'est un cas relativement rare et généralement celui qui update va faire une correction qui est un mixe des deux.
 
Enfin, il y a la livraison. Dans le cas de CVS, on dit le commit. Après un dernier update pour être sur qu'il n'y a pas de cas de conflits, on tape un "cvs commit nomDuModule". Chaque fichier est comparé avec ce qu'il y a sur le serveur. Les fichier ayant une modification sont mis à jour sur le serveur et leur numéro de version incrémenté. Ils sont dispo pour les autres.
 
CVS est très interressant en développement collaboratif pour plusieurs raisons.
- c'est un projet libre très mature. D'énormes projets l'utilisent depuis la nuit des temps sans aucun problèmes.
- Sa granularité très fine permet de se séparer le travail très finement, sans risques de se bloquer (actuellement, j'utilise un système à lock, je passe mon temps à faire chier celui qui lock une classe importante pour qu'il me fasse des modifs).
- Il est très bien intégrés aux IDE. Je file des commandes pour l'exemple, mais tout IDE digne de ce nom dispose d'une interface rendant quasi transparente l'utilisation de cvs.  
- Il est plutot rapide. Je suis toujours épaté par sa vitesse de réaction et sa faible occupation mémoire.  
 
Bon, on va grogner un peu quand même et dire quelques défauts.
- CVS ne gère que des fichiers. Il ne sais pas ce qu'est un répertoire. Dans mon application, je doit avoir un répertoire temporaire vide dispo au check out, j'ai été obligé de créer un ficheir vide dedans pour que CVS daigne me le créer.
- L'identification d'un fichier est son nom. Si il faut renommer un fichier, pour CVS, cela signifie supprimer le fichier précédent et ajouter le nouveau, qui redemmarera avec un numero de version à 0.
- Le merge de branches est incompréhensibles. Dans la vraie vie, je ne connais personne qui utilise ce truc.
- C'est un truc de nerdz barbu
 
Une ch'tite doc : http://www.graoulug.org/documentat [...] n/CVS.html
 
Le contenu du repository CVS d'apache : http://cvs.apache.org/viewcvs.cgi/

cvs c'est bien sauf quand un manager a la con impose un usage completement absurde
 
 
kadreg >> pour les repertoies, y'a subversion qui versionne aussi les repertoires sinon, euh question de curiosité: pq ton processus de build (ou autre) ne crée t'il pas ce repertoire temp dont tu as besoin?  
(si tu fais ton update sans le -P (prune) mais avec le -d (create dirs), il devrait te le creer meme vide, non??)
 
kadreg toujours >> les branches c'est utile pour corriger une version en prod qui a continué a evoluer en dev //ment. et pour un bug fix simple le merge est pas compliqué. (cvs update -j HEAD; cvs commit; cvs update -r HEAD et le switch pour virer les sticky tags; qqchose comme ça...)
Par contre, quand ... [voir ma 1ere remarque sur le manager con], alors là c'est galère: cet imbécile veut qu'on fasse une branche pour chaque "task" qui nous est assignée sur le projet. Apres c'est la fête du slip pour merger. Surtout que, vu qu'on bosse en parallèle, on a besoin de faire des updates depuis les branches des autres
quel con

 
Je sais. Il a l'air de bien avancer ce pépère.
 

 
On a de très vieilles procédures automatisées d'intégration qui, pour créer les versions clients, font des co à la brutale et sans builds tels qu'on les connais normalement.  
 
 

 
Toutafé, c'est comme cela qu'on utilise les branches d'ailleurs. Sauf que des modifs de la branches de maintenance sont parfois reportés sur la branche de dev. après avoir longtemps évolué parallèlement, et là, il arrive que ce soit plus chaud, mais on utilise un autre outil pour cela (je ne détaillerais pas).
 

 

 
J'ai la chance d'avoir un manager qui a imposé CVS après l'avoir sérieusement utilisé ailleurs. Globalement, on se plaint pas. Même si il n'est pas utilisé partout ou il pourrait et que l'on uilise d'autres technos.

si tu le connais, tu pourras ptet repondre à deux questions: 1/j'ai cru lire qu'il se basait sur une bdd? j'ai revé?
2/ j'ai aussi cru lire que ct en java? j'ai revé??
 

le pire c'est que bien avant qu'il n'arrive (avant que moi je n'arrive et avant que son predecesseur n'arrive d'ailleurs), on utilisait deja CVS de maniere normale...  
le seul avantage qu'il y a à son truc c'est pour faire du code review d'une modif qu'un autre à fait... mais avec une utilisation normale, tu peux tres bien le faire aussi, à condition de le faire tout de suite (ce qui serait une bonne chose)

 
1/ Non, c'est une berkeleyDB. C'est un système de DB tout con (fichier contenant des données) et pas un SGDB.  
 
2/ il y aura plusieurs client, dont certains en java. Exemple : http://jsvn.alternatecomputing.com/. Mais le moteur serveur est en C si ma mémoire est bonne.

ha ok
mais donc il y a un moteur serveur
(contrairement à cvs, sauf si on utilise pserver, mais en ssh y'a rien, ou alors j'ai rien pigé)

 
Mouais.
 
En fait le serveur est un module apache (2) utilisant un module web-dav et utilisant les bibliothèques subversions pour acceder au repository.
 
http://subversion.tigris.org/proje [...] -extension

ça va pas etre méchament plus lent à ton avis

>>>kadreg
Au niveau du suivi des versions, les check-in/check-out, c est pas l inverse ??
sur clearcase :  
check-out te permet de modifier un fichier et check in de le remettre dans la branch
 
>>>>kadreg :  
les modules, c est bizarre de pouvoir gerer ca.
le projet sur lequel je bosse. je peux avoir des modifs a faire sur une dizaine de fichier. qui sont pas forcement dans le meme module, mais dans 10 modules differement. donc j ai du mal a voir l interer.
 
>>>>kradreg:
le merge de branch, pas d interet
tous les deux jours, il y a une release du projet, avec une dizaine de branch testée qu il faut merger!!! (et entre chaque release, il y a des pre-release )
 
 
en tout cas. au debut je trouvait que c etait la galere. mais c est quand meme tres puissant comme outil !!

Nous, on utilise PVCS VM de Merant. C'est un produit peu fonctionnel et très cher.

 
Si, mais il était tard
 

 
Le module est sens CVS est quelque chose de plus global que ce que tu dit. Une modification doit impacter plusieurs fichiers, ces fichiers doivent être dans le même module. De nombreux projet n'ont d'ailleurs qu'un seul module dans leur CVS (monapplication). Regarde le contenu du CVS apache, chaque module est une application différente.
 
 

 
La notion de branche est peut être différente entre CVS et Clearcase. Parceque à ce que tu me dit, une branch dans ce projet ne correspond pas du tout à la notion de branch CVS.
 

 
Oui. C'est une petite contrainte au début, mais ceux qui ont tenté de développer en collab sans ce type d'outils ont mangé leurs mains.

pour ClearCase:
 
quand je veux faire une modif, sans gener personne.  
 
je cree une branch :   slvn_br  (la branch est vide au debut)
je cree une view tel que :
  la view pointe sur tout les element Checkout
  puis sur tout les element "latest" de ma branch
  sur tout les element "latest" de la main branch
 
et je parametre ma  view pour que tout les element que je check-in, soit check in dans ma branch.
 
donc des que je fais une modif, c est:  
Checkout depsui la main_branch, modif, check_in dans ma branch.
 
et au final. (apres des heure boulot et de web browsing ), ma branch contient une certaine quantite de fichier qui sont differenent de la main branch.
 
voici pour la notion de branch sous ClearCase ... ou plutot la maniere dont on s en sert. ...mais bon je vois mal comment faire autre chose.
 
voila, sinon, faut s imaginier que parallement, chacun travaille sur sa/ses branch, et qu a la fin il faut tout rassembler. donc il faut tout merger. (d abord merger sa branch sur la dernier version du projet(car il y a souvent des realease en temps), puis merger tout les branchs pour faire la nouvelle release .