====== SVN vs CVS ======


===== Introduction =====


Je suis en train de regarder le système de gestion de version nommé [[http://fr.wikipedia.org/wiki/Subversion_(logiciel)|subversion]] (ou SVN en abrégé). Ce nouveau système remplacera progressivement CVS pour beaucoup de projets ([[http://sourceforge.net/|sourceforge]] entre autres).



===== Pourquoi changer? =====

Les problèmes suivants apparaissent avec CVS:
  * Chaque fichier a un numéro de version propre - si bien qu'on ne peut pas sortir une version donnée sans mentionner une date (parfois difficile à trouver) ou un tag (souvent pas fait). **C'est le problème majeur actuel: pour l'instant, on sort des versions et puis on ne sait plus les identifier!**  
  * Impossibilité de renommer/déplacer un fichier en gardant l'historique. Actuellement, quand c'est trop bordélique, on crée un nouveau repository, on perd toute l'historique, et donc, on ne sait plus maintenir les versions antérieures sans jongler avec plusieurs repositories! ... Et si même on n'a pas changé de repository, si le fichier qu'on veut patcher a changé de nom ou a été déplacé, il faut tout faire à la main!
  * La gestion des caractères de fin de ligne (EOL) est tellement automatique avec CVS que le nouveau bash, sous cygwin, refuse de fonctionner (les scripts shells contiennent les codes Windows CRLF de fin de ligne).
  * Nous devons utiliser une vielle version de WinCVS parce que les nouvelles versions de cet outil ne sont plus compatibles avec le CVS classique qu'on trouve sous Unix/Linux.
  * CVS est un vieux système démodé. 









===== Présentation de subversion =====

Subversion (édité en GPL par [[http://subversion.tigris.org/|Tigris]]) permet de résoudre tous ces problèmes:
  * Chaque commit a un numéro propre (on parle de commit "atomique"). Impossible de commiter par erreur la moitié de ses fichiers parce que svn aurait planté en cours de commit. C'est tout ou rien. Cependant, rien n'empêche de faire son commit en plusieurs étapes (commit des fichiers batteries a part).
  * Possibilité de conserver l'historique lors de déplacement de fichiers (très utile lors des nettoyages).
  * Possibilité de customiser la gestion des caractères en fin de ligne (problème du nouveau bash résolu).
  * Il existe un client Windows nommé [[http://tortoisesvn.tigris.org/|TortoiseSVN]] qui permet d'éviter la ligne de commande.
  * Autres:
     * Gestion "intelligente" des copies de fichiers: on peut dupliquer un ficher; dans ce cas, chaque copie évoluera séparement mais partagera l'historique d'avant la duplication. En particulier, si on ne modifie pas la copie, celle-ci ne prendra aucune place dans le repository.
     * Répertoires/Tags/Branches sont des concepts identiques. Ce sont des copies du tronc principal (nommé par convention ''trunk'').
     * Gestion correcte des fichiers binaires.
     * possibilité d'ajouter des propriétés (texte et même fichiers) au fichiers. Par exemple: un copyright, des notes, des codes de config du client svn, etc.
\\
\\

__Question "philosophie"__, Subversion (SVN) et CVS, c'est identique:
  * Les données sont stockées dans un repository. SVN permet plusieurs manières d'y accéder (accès direct, apache, serveur dédié ou ssh) et plusieurs format de repository (Berkley DB ou FSFS). Si on utilise la méthode d'accès ssh, on est exactement dans la même config qu'actuellement avec cvs.
  * On fait un checkout (''svn co'')
  * On travaille (modif du source)
  * On update (''svn update'') -- on règle les conflits et on les signale "résolus" (''svn resolve'')
  * On commite (''svn commit'')
\\
\\

Bref, peu de choses changent... J'ai donc testé l'utilisation de SVN dans différentes configs critiques:
  * Compilation SVN (client): OK partout même sur chinook.
  * Installation Serveur: OK (testé sous Linux et Windows)
  * Transfert d'une working-copy par fichier zip+FTP: OK
  * GUI: [[http://tortoisesvn.tigris.org/|TortoiseSVN]] sous Windows (très bon!), [[http://rapidsvn.tigris.org/|RapidSVN]] (bof -- ssh marche pas), [[http://subcommander.tigris.org/|Subcommander]] (très bof -- laid), [[http://www.syntevo.com/smartsvn/|SmartSVN]] (ok pour usage normal), etc.
  * Tarball du repository sous Linux et utilisation sous Windows: OK.
  * Remplacement des tags ''$Id$'': OK (peut être désactivé totalement ou en partie). Ces tags ne sont pas stockés dans le repository (pas de merdes lors des fusion de branches).


===== Pourquoi ne pas changer? =====

Qu'est ce qui nous pousserait à ne pas changer? Voilà quelques points à considérer:
  * A part TortoiseCVS, j'ai rien vu de fameux comme GUI sous Windows. Ce programme s'intègre à l'explorer et il est très complet. La seule chose qui manque est la vue ("flat view") de WinCVS. Cependant, on peut obtenir une vue similaire en effectuant un "SVN - Check for modification" (''svn status'').
  * Il faut créer un nouveau repository (celui-ci contiendra peut-être l'historique CVS si j'arrive à migrer le repository actuel). Cela nécessite que tout le monde soit à jour sur la dernière version.
  * svn+ssh demande beaucoup plus souvent le mot de passe que cvs+ssh. Il est donc presque indispensable de configurer sa machine client pour permettre un login sans entrer le mot de passe.
  * Il faut configurer le client SVN pour qu'il reconnaissent les fichiers textes lors d'un add/commit. Cette config doit être effectuée sur chaque client (et pas au niveau du serveur). 

En ce qui me concerne, je ne trouve pas que ces derniers points soient de gros inconvénients.






===== Comment pouvont nous gérer un no de version avec SVN? =====

Même si SVN donne un numéro de version par commit, les numéros des versions stables risquent de ne pas se suivre (en général, on commite en plusieurs fois). Deux solutions:
  * Se forcer à commiter en 1 seule fois. Ca implique de rappatrier ses batteries sur PC et commiter tout en même temps (et ne pas oublier certains fichiers ajoutés).
  * Soit commiter comme maintenant et marquer dans la page de commit le numéro de version du dernier commit.

Je crois que la 2ieme solution est la seule faisable en pratique...

__Autre problème:__ comment lier (automatiquement) un exécutable à un numéro de version (qui s'afficherait lors du lancement de Metafor)? [C'est quand même la raison pour laquelle j'ai fait cette petite étude...]

On peut créer un post-build step du type:

   svnversion oo_meta > oo_meta/version.txt

ca crée un fichier ''version.txt'' (qui contient le fameux numéro de version de ''oo_meta'' -- global pour le dernier commit) qui peut être inclus dans le source et compilé. Et voilà!




===== Remarques de L.Stainier =====

Quelques remarques supplémentaires issues de ma propre expérience:
    - les manips de déplacement, suppression de répertoires fonctionnent vraiment bien!
    - la possibilité d'utiliser https comme protocole d'authentification est intéressante: ça permet d'utiliser une liste d'utilisateurs différente des comptes utilisateurs unix du serveur, et de gérer les autorisations répertoire par répertoire sans devoir créer 5000 groupes et se casser la tête...
    - dans le cas https au moins, il est possible de garder le mot de passe en "cache" et de ne plus avoir à l'introduire à chaque opération
    - un avantage incroyable de SVN sur CVS est que plusieurs opérations peuvent être faites off-line, càd sans accès au repository (pas le commit ou le update évidemment), chose bien utile pour les grands voyageurs !-)
    - de manière complémentaire, certaines opérations peuvent être réalisées sans working copy, directement sur le repository.

Pour la gestion du numéro unique de version, je crois qu'il faudra de toute façon se reposer sur la bonne volonté des utilisateurs. Il n'y en a quand même pas tant que ça qui font des versions "de référence".