Je peux vous garantir qu'une fois qu'on a utilisé SubVersion, CVS ressemble à un dinosaure, et on se demande pourquoi on utilise encore cet outil *désuet* à l'heure actuelle !!! Ce qui change :
— On peut charger uniquement une partie du dépôt et bosser dessus (dans CVS, ça se passe par "module")
— On n'a pas besoin de se connecter au serveur pour faire un ajout ou une suppression (chose que je n'ai jamais comprise dans CVS) : ceci rend la préparation d'un commit beaucoup plus agréable
— Un diff par rapport à la dernière version commitée se fait sans se connecter au serveur (chose magnifique), de même pour avoir avec "status" de répertoire local (ça fait tout bizzare au début de ne pas avoir à attendre 5 min ;-)). De plus "status" est très bien présenté (affiche juste les fichiers qui ne sont pas dans le dépot, les fichiers ajoutés / supprimés, et les fichiers modifiés) : juste comme il faut
— Un commit SVN est moins bavard qu'un CVS qui remplit l'écran de plein de griboulli
— On peut créer un répertoire avec SVN (remplace un mkdir X; cvs add X; => lourd à cause de la connexion au serveur pour rappel)
— Il existe une fonction "magique" (quand on vient du monde CVS) : svn revert qui permet de revenir à la dernière version commitée
— Un update ajoute automatiquement les nouveaux fichiers (pas besoin d'ajouter -A à la commande)
— Le répertoire utilisés par SVN sont nommés ".svn", et sont donc cachés. Ceci est plus sympa que les répertoires CVS trop visibles à mon goût.
— La création de branche est plus pratique, il suffit de dupliquer un répertoire autre part, et hop, on a une branche ...
— Les numéros de versions (de commit) sont simplement incrémentés (1, 2, ...). C'est plus simple que des 1.1.1, 1.2.34, 1.54, ... (bon ok, c'est discutable, et je crois bien que CVS est plus souple à ce niveau là)
— Avec l'interface web (CvsWeb, qui comme son nom ne l'indique pas, sait aussi afficher du SubVersion) on peut voir l'ensemble des modifications d'un commit. Chose que je n'ai jamais réussi à faire avec CVS (peut-être avec un cvs history <options magiques> ?).
— Et puis il y a sûrement plein d'autres avantages. Pour rappel, SVN a été écrit car CVS a été mal pensé niveau sécurité (voir des sites de sécurité et compter le nombre de failles ...) et pour corriger les défauts de conception de CVS.
En fait, SVN duplique chaque fichier lors du premier "checkout", c'est pourquoi diff/status est si rapide (et revert possible).
J'ai jamais passé de dépôt CVS en SubVersion, mais il parait que ça se fait bien. Pour info, http://developer.berlios.de/(...) permet d'avoir un dépôt CVS et/ou SubVersion. C'est un des seuls à ma connaissance.
Pour info, HappyBoom est mon projet de réécriture de Wormux en Python et SDL, qui est aujourd'hui un projet expérimental de moteur réseau avec un système multi-agents.
@+ Haypo étonné de tartiner tellement sur cet outil ;-)
# Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) ...
Posté par Victor STINNER (site web personnel) . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 10.
— On peut charger uniquement une partie du dépôt et bosser dessus (dans CVS, ça se passe par "module")
— On n'a pas besoin de se connecter au serveur pour faire un ajout ou une suppression (chose que je n'ai jamais comprise dans CVS) : ceci rend la préparation d'un commit beaucoup plus agréable
— Un diff par rapport à la dernière version commitée se fait sans se connecter au serveur (chose magnifique), de même pour avoir avec "status" de répertoire local (ça fait tout bizzare au début de ne pas avoir à attendre 5 min ;-)). De plus "status" est très bien présenté (affiche juste les fichiers qui ne sont pas dans le dépot, les fichiers ajoutés / supprimés, et les fichiers modifiés) : juste comme il faut
— Un commit SVN est moins bavard qu'un CVS qui remplit l'écran de plein de griboulli
— On peut créer un répertoire avec SVN (remplace un mkdir X; cvs add X; => lourd à cause de la connexion au serveur pour rappel)
— Il existe une fonction "magique" (quand on vient du monde CVS) : svn revert qui permet de revenir à la dernière version commitée
— Un update ajoute automatiquement les nouveaux fichiers (pas besoin d'ajouter -A à la commande)
— Le répertoire utilisés par SVN sont nommés ".svn", et sont donc cachés. Ceci est plus sympa que les répertoires CVS trop visibles à mon goût.
— La création de branche est plus pratique, il suffit de dupliquer un répertoire autre part, et hop, on a une branche ...
— Les numéros de versions (de commit) sont simplement incrémentés (1, 2, ...). C'est plus simple que des 1.1.1, 1.2.34, 1.54, ... (bon ok, c'est discutable, et je crois bien que CVS est plus souple à ce niveau là)
— Avec l'interface web (CvsWeb, qui comme son nom ne l'indique pas, sait aussi afficher du SubVersion) on peut voir l'ensemble des modifications d'un commit. Chose que je n'ai jamais réussi à faire avec CVS (peut-être avec un cvs history <options magiques> ?).
— Et puis il y a sûrement plein d'autres avantages. Pour rappel, SVN a été écrit car CVS a été mal pensé niveau sécurité (voir des sites de sécurité et compter le nombre de failles ...) et pour corriger les défauts de conception de CVS.
En fait, SVN duplique chaque fichier lors du premier "checkout", c'est pourquoi diff/status est si rapide (et revert possible).
J'ai jamais passé de dépôt CVS en SubVersion, mais il parait que ça se fait bien. Pour info, http://developer.berlios.de/(...) permet d'avoir un dépôt CVS et/ou SubVersion. C'est un des seuls à ma connaissance.
Pour voir à quoi ressemble à CvsWeb de SVN (y'a un p'tit bug UTF-8 par contre, peut-être parce que je suis en UTF-8 et pas le serveur) :
http://svn.berlios.de/viewcvs/happyboom/trunk/(...)
Pour info, HappyBoom est mon projet de réécriture de Wormux en Python et SDL, qui est aujourd'hui un projet expérimental de moteur réseau avec un système multi-agents.
@+ Haypo étonné de tartiner tellement sur cet outil ;-)