S'il vous plait, oubliez tous CVS
Par Laurentj le mardi, décembre 12 2006, 14:43 - Logiciels - Lien permanent
Plus j'utilise Subversion, plus je hais CVS[1] (qu'il faut bien que j'utilise, par exemple pour Mozilla). Avec subversion, les commandes sont simples et relativement intuitives, sans 50 paramètres à ajouter pour faire un truc normal. Avec CVS, c'est un cauchemar.
Tenez par exemple, j'ai modifié un fichier. Je veux annuler les modifications, donc revenir à la version que j'avais téléchargée du dépot. Avec subversion, c'est trés simple : svn revert nom_du_fichier. Et sans avoir à contacter le serveur. Avec CVS.. On ne peut pas. Du moins pas directement (effacer le fichier, regarder dans le fichier entries pour avoir le numéro de version, faire un CVS update avec ce numéro...). Et faut être connecté.
Au passage, vivement que Mozilla abandonne CVS. C'est d'ailleurs ce qu'ils prévoient. Depuis quelques semaines, ils étudient sérieusement d'autres systèmes de gestion de versions. Mais pas évident de choisir vu les prérequis. Subversion pourrait être un bon candidat, mais d'autres aussi : c'est un véritable "combat mortel" entre chaque solution existante :-)
Notes
[1] CVS et Subversion sont des gestionnaires de versions de fichiers)
Commentaires
Subversion est déjà éliminé. Ceci-dit la gestion des branches et des merges avec subversion c'est vraiment pas la panacé.
Cela depend ce que l'on attend d'une gestion de branches et de merges. svn copy pour créer une branche, svn merge pour faire un merge (+ creation de fichiers aux noms explicites pour les conflits). Un repertoire pour chaque branche etc. Bref, cela a rendu CVS trés trés obsolète.
Bon il se trouve que Mozilla a de plus fortes exigeances. Mais il va falloir qu'ils fassent gaffes : utiliser un système peu connu, peu utilisé, et avec un fonctionnement radicalement différent conceptuellement parlant (les systèmes de version distribués), cela risque de provoquer des rejets ou des mécontentements... Pour ma part je trouve que Subversion est un bon candidat, parce que la rupture est douce par rapport à CVS : mêmes principes, commandes similaires (mais plus simple et fonctionnelles) etc...
cvs update -C <nomdufichier> est equivalent à svn revert <nomdufichier> non ?
Un article intéressant : http://keithp.com/blog/Repository_Formats_Matter.html
Sinon, il y'a Visual Source Safe... (Ok, je suis déja dehors, et il fait froid.)
Plus j'utilise git et plus je hais SVN...
Plus sérieusement je suis un utilisateur régulier de git et je suis globalement d'accord avec l'article de Keith Packart sus-cité. À mon avis les prochains changements de SCM ne se feront pas tant vers SVN mais plutôt vers git ou Mercurial.
S.F. : pour les gros projets, c'est probable. Mais pour les petits projets, subversion est largement suffisant je pense.
Il n'y a bien que Mozilla pour ne pas avoir migré, il était temps... Pour les gros projet réussissant sous SVN, entre KDE et Sourceforge, y'a pas photo, ça a beau être du bloatware (heu, "logiciel complexe, un peu beaucoup trop par rapport à ce que ça fait" :D ), Mozilla ne fait absolument pas le poids ^^. Bref, aucun problème.
Moi ça me désole d'en voir se raccrocher comme ça au passé. Mon proj' actuel, j'ai plaidé encore et encore pour SVN, mais comme le chef de prof' a passé 30 ans depuis un bon bout de temps, c'est CVS qu'il nous a collé. Et encore, faut être content, ça aurait pu être cette vieille daube pourrie de clearcase (aussi répandu que détestable, on imagine mal jusqu'à quel point ; heureusement, c'est très cher).
Sinon, autre que SVN, ce serait Mercurial ? Étant donné l'allure code mozillien, ça serait une mauvaise idée de mettre un système de versioning trop intelligent, sous peine de ramer comme ce n'est même pas permis. J'ai déjà vu des systèmes de ce type (Arch) mettre plus de 24h pour faire un merge un peu trop complexe (quelques centaines de lignes sur plusieurs milliers à peine), il faut commiter très très souvent, et la détection des deadlocks n'est pas garantie.
Bref, en allant faire un tour sur wikipedia on se rend compte que l'on a vite fait le tour, et comme un système à la Git ne correspondrait pas du tout à ce qui est attendu (mais ce n'est que mon avis, Mozilla c'est pas codé du tout pareil que Linux dans son fonctionnement), il ne reste plus que SVN.
"Mais il va falloir qu'ils fassent gaffes : utiliser un système peu connu, peu utilisé, et avec un fonctionnement radicalement différent conceptuellement parlant (les systèmes de version distribués), cela risque de provoquer des rejets ou des mécontentements..."
Un truc à la Git alors ? Mouarf, comme dit plus haut, je le sens pas du tout cette histoire. Y'a pas le système de détection de bug aussi à changer (le machin proprio qui fait 3 fois rien, là, avec la base sous windaube me semble-t-il) ? C'est la foire aux mauvaises idées, décidément ^^ (et pourtant, encore une fois : KDE c'est plus de 4 millions de lignes de code, et certainement plus de contributeurs ; en tout cas ça fait carrément plus de choses au final, donc s'il le peuvent, Mozilla le peut aussi, nan ?).
Rhooo.... le vilain troll :)
Le machin proprio est en train de changer vers airbag, je ne vois pas ce que ça vient faire ici.
Mozilla, c'est, je crois presque 7 millions de lignes de codes... donc bon, on repassera pour la comparaison avec KDE.
Niveau contributeurs, je ne sais pas où en est KDE, mais côté Mozilla, 200 codeurs régulier, 25.000 comptes bugzilla ouverts. Si on compte tout ce qui n'est pas purement code, le nombre est estimé à 40.000.
Bon... n'empêche qu'ils prennent leur temps, et ils ont bien raison. Ce n'est pas quelque chose de simple, surtout vu le processus de build qui est fortement lié au cvs.
Donc que KDE soit plus rapide à avoir faire ce choix, et savoir qui a la plus grosse... je m'en fout.
Je fais pleinement confiance aux gars de Mozilla pour faire le choix correct, et ça fait un bout de temps qu'ils se prennent la tête avec ça (processus de build et systeme de versionning).
7 millions ?? o_O My god, no comment......
(heu, t'es sûr ? Parce que ça met moins de temps pour compiler ; en même temps, c'est C vs C++, mais quand même...)
moi j'ai un projet a 50 millions de lignes. en fait j'ai 5 millions de branches de 10 lignes.
Alors qui qui la plus grosse ?
palpatine : KDE c'est du C++ il me semble (comme Mozilla).
Pour le nombre de ligne de code, c'est à vérifier. Que comprend ce nombre ? juste le c ? le c et les commentaires ? le c++, les fichiers xml etc ?
d'autant que je ne trouve aucune stats sérieuses, mis à part sur http://www.ohloh.net/ mais les stats sont scindées pour chaque sous projet de KDE et de Mozilla.
Si on s'en tient au coeur des deux projets (et juste le code) :
(bon aprés, vu le nombre d'appli qu'embarque KDE, et vu le "peu" de ligne de code qu'il faut pour faire une appli mozilla, KDE est effectivement plus gros..)
M'enfin bon, la nature des projets et leur organisation du developpement étant différents, la comparaison entre les deux n'est pas trés pertinente, et leurs besoins en terme de gestionnaire de version ne sont pas les mêmes.
KOffice (en annexe à KDE, mais sur le même SVN) fait 750.000 lignes à lui tout seul, et les chiffres viennent directement de la team ; le reste du décompte, ça a été annoncé... lors de la migration vers SVN ^^. J'ai bossé sur du prog à 360.000 lignes (Ada pour 85%, facile à compter) géré successivement par clearcase et CVS, et le truc ne faisait clairement pas grand chose...
Bref, le problème c'est surtout le nombre de commits à gérer, et la difficulté à faire des merges. J'ai vu des fichiers sous Kopete il y a deux ans qui faisaient plus de 5000 lignes, le pur bonheur à compiler à l'époque (la mémoire que ça bouffe, proprement impressionnant). Quant à Mozilla, c'est loin d'être trivial aussi, et autant KDE est très parsemé, de telle sorte que SVN est meilleur que Git tout simplement parce que le projet est scindé en une myriade de sous-autres, autant pour Mozilla, axé essentiellement sur une politique centralisée à travers de gros contributeurs (faisant même bien râler Debian à propos de Firefox ;) ), ça me semble vraiment pas adapté du tout d'avoir chacun sa version, de manière décentralisée. Pour Linux, la justification est plus simple, et est due à l'organisation en modules, associée à une distribution des développeurs tout autour du monde, qui ne forment pas vraiment de noyaux cohérents entre eux (d'où les kernel summits...).
M'enfin, l'avenir dira, mais pour l'historique, c'est assez délicat en plus de partir sur des bases aussi éloignées de l'ancien modèle, un retour en arrière peut s'avérer fort difficile...