doc:devel:svn
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revision | Last revisionBoth sides next revision | ||
doc:devel:svn [2009/06/14 13:45] – boman | doc:devel:svn [2016/03/30 15:23] – external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== SVN vs CVS ====== | ||
+ | |||
+ | |||
+ | ===== Introduction ===== | ||
+ | |||
+ | |||
+ | Je suis en train de regarder le système de gestion de version nommé [[http:// | ||
+ | |||
+ | |||
+ | |||
+ | ===== 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' | ||
+ | * Impossibilité de renommer/ | ||
+ | * 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:// | ||
+ | * Chaque commit a un numéro propre (on parle de commit " | ||
+ | * Possibilité de conserver l' | ||
+ | * 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:// | ||
+ | * Autres: | ||
+ | * Gestion " | ||
+ | * Répertoires/ | ||
+ | * Gestion correcte des fichiers binaires. | ||
+ | * possibilité d' | ||
+ | \\ | ||
+ | \\ | ||
+ | |||
+ | __Question " | ||
+ | * 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' | ||
+ | * On fait un checkout ('' | ||
+ | * On travaille (modif du source) | ||
+ | * On update ('' | ||
+ | * On commite ('' | ||
+ | \\ | ||
+ | \\ | ||
+ | |||
+ | Bref, peu de choses changent... J'ai donc testé l' | ||
+ | * 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:// | ||
+ | * Tarball du repository sous Linux et utilisation sous Windows: OK. | ||
+ | * Remplacement des tags '' | ||
+ | |||
+ | |||
+ | ===== Pourquoi ne pas changer? ===== | ||
+ | |||
+ | Qu'est ce qui nous pousserait à ne pas changer? Voilà quelques points à considérer: | ||
+ | * A part TortoiseCVS, | ||
+ | * Il faut créer un nouveau repository (celui-ci contiendra peut-être l' | ||
+ | * 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: | ||
+ | |||
+ | On peut créer un post-build step du type: | ||
+ | |||
+ | | ||
+ | |||
+ | ca crée un fichier '' | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Remarques de L.Stainier ===== | ||
+ | |||
+ | Quelques remarques supplémentaires issues de ma propre expérience: | ||
+ | - les manips de déplacement, | ||
+ | - la possibilité d' | ||
+ | - dans le cas https au moins, il est possible de garder le mot de passe en " | ||
+ | - 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), | ||
+ | - de manière complémentaire, | ||
+ | |||
+ | 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" | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||