|
|
Mettre en oeuvre CVS avec Visual Studio .NET 2003 par Laurent Desmons | |
|
|
|
La véritable puissance d'un environnement de développement aussi complet que Visual Studio .NET 2003 ne peut s'exprimer que si on place le code source sous contrôle. Il est nécessaire en effet de disposer d'un référentiel de code source que l'ensemble des développeurs partage et met à jour en commun efficacement, sans crainte et avec un maximum de productivité et de confort au quotidien. J'ajoute que les développements modernes basés sur de vrais composants objets et des architectures multi couches favorisent la réutilisation du code source et, par là même, multiplient les risques de conflits ou, pire, de pertes, en cas de modifications concurrentes apportées sur des fichiers communs sans filet de protection ni gilet de sauvetage.
Il existe plusieurs logiciels spécialisés dans le contrôle de code source et qu'on peut intégrer dans un environnement de développement fondé sur Visual Studio .NET 2003. La combinaison gagnante que je vous propose de mettre en place au cours de cet article est la suivante :
Cet article est destiné en priorité aux équipes de développement qui n'ont pas encore intégré un contrôle de code source dans leurs outils quotidiens. Mais il est également destiné à ceux qui sont sous Visual Source Safe, car je les encourage vivement à faire le pas vers CVS. Côté Visual Studio .NET en effet, rien ne change : tout se passe dans les coulisses, et du côté du serveur CVS.
Cela dit, il faut se rendre compte que mettre en oeuvre un contrôle de code source dans un environnement .NET n'est pas toujours facile :
Cet article n'est pas un cours sur CVS. Je vais simplement m'efforcer de vous guider tout le long de sa mise en oeuvre dans un environnement de développement fondé sur Visual Studio .NET 2003, et terminer par des conseils pratiques issus d'expériences concrètes. Mon objectif est de vous aider à faire le pas, décisif, vers l'intégration d'un logiciel de contrôle de code source dans votre travail quotidien : les bénéfices sont immenses, et on ne peut vraiment plus s'en passer ensuite.
Je vous propose de suivre plusieurs étapes définies par le plan suivant :
CVS fonctionne selon un mode client serveur. Le serveur maintient la référence du code source dans ce qu'on appelle le Repository, qui est simplement un répertoire dans lequel se trouvent les fichiers sources partagés. Le Repository est découpé en modules qui regroupent logiquement un ensemble de fichiers : de façon simple, à chaque solution Visual Studio .NET on peut faire correspondre un module CVS. Chaque module est physiquement stocké dans un sous-répertoire du Repository. La fonction principale du serveur CVS est de s'occuper de gérer les accès concurrents aux fichiers et de maintenir un Repository à jour et stable, à disposition de tous ses clients.
CVS stocke les modifications apportées à chaque fichier de façon incrémentale : à chaque modification d'un fichier correspond un numéro de révision que CVS attribue automatiquement à ce fichier. Pour obtenir la révision 1.2 d'un fichier, CVS doit d'abord reconstruire l'ensemble des révisions de ce fichier depuis sa création : 1.0, puis 1.1 et enfin 1.2. CVS donne ensuite la possibilité d'attribuer un numéro de version à un ensemble de fichiers : cette notion de version est indépendante de la notion de révision, et permet une grande souplesse dans la gestion des versions successives d'un projet.
Chaque développeur utilise la partie cliente de CVS. Tout est rendu transparent dans Visual Studio .NET car la partie cliente de CVS est prise en charge par un plug-in qui doit respecter les spécifications Microsoft SCC (Source Code Control) pour s'intégrer dans l'environnement de développement. Chaque développeur dispose d'une copie locale des sources d'un module, obtenue initialement par l'intermédiaire du serveur CVS. Le développeur ne travaille que sur cette copie locale sur sa machine, sans jamais manipuler directement le Repository : c'est à Visual Studio .NET qu'il incombe d'effectuer les accès nécessaires au serveur CVS pour :
Les fichiers qui constituent la copie locale de chaque développeur sont en lecture seule. Pour apporter des modifications à un fichier, le développeur doit d'abord extraire ("check-out") le fichier depuis le repository, ce qui a pour effet de :
Le développeur qui désire ensuite valider ses modifications dans le Repository, afin que cela devienne la version de référence, doit alors ensuite archiver ("check-in", ou "commit") le fichier dans CVS. Le serveur CVS s'occupe ensuite de tout, et notamment de la fusion des modifications apportées sur un même fichier par plusieurs développeurs. Le développeur n'a pas à s'inquiéter de quoi que ce soit.
Nous verrons que, pour le développeur, l'ensemble des ces manipulations se fait par l'intermédiaire de menus dans l'environnement de développement. Chaque développeur peut ainsi profiter de la souplesse et des performances du contrôle de code source CVS de façon transparente, sans jamais quitter Visual Studio .NET, et donc sans jamais perturber ses habitudes de travail, parfois chèrement acquises.
Avant de commencer, il faut préparer le serveur CVS :
net stop cvs |
Le cadre d'exploitation de CVS étant maintenant préparé, nous allons procéder à l'installation de CVS.
La version Windows du serveur CVS s'appelle CVSNT et peut se télécharger à partir de la page suivante : http://www.cvsnt.com/cvspro/. Cette installation doit être effectuée sur le serveur, ainsi que sur chaque poste client. Une fois l'EXE téléchargé, il suffit de cliquer dessus pour commencer l'installation :
Il suffit ensuite d'accepter la licence et d'installer CVS dans le répertoire de son choix pour continuer l'installation. L'écran suivant permet de sélectionner les composants à installer, et de choisir le type d'installation (client ou serveur) ainsi que les protocoles de communication utilisés par CVS :
Dans le cadre de cet article nous utliserons le protocole simple "pserver", qui permet une communication sécurisée sur la base d'un couple user/password, mais tout ce qui suit s'applique aussi aux autres protocoles (se reporter à la documentation pour leur présentation). Le dernier écran permet d'installer des composants destinés uniquement à la partie serveur de CVS (tout décocher sur les postes clients):
Une fois l'installation terminée, il faut configurer le serveur CVS afin de créer le Repository.
Le panneau de contrôle du service CVSNT apparait dans le panneau de configuration Windows, avec son traditionnel poisson vert pomme :
On accède à la configuration du serveur CVSNT en double-cliquant sur le petit poisson vert.
La première chose à faire est d'arrêter les services CVS en cliquant sur les deux boutons "Stop". Ensuite :
C'est suffisant. Ceux qui sont intéressés par les autres options avancées peuvent toujours se référer à la documentation. Nos manipulations ont conduit à la création d'un module (ou répertoire, si vous préférez) CVSROOT, directement sous le Repository :
Maintenant que le Repository est créé et que le serveur CVS est configuré, CVS est directement exploitable en ligne de commande DOS. Il est cependant préférable (mais pas indispensable) de positionner la valeur d'une variable d'environnement Windows qui doit s'appeler CVSROOT et dont CVS se sert afin de savoir comment accéder par défaut au Repository.
Positionner cette variable aussi bien sur les postes clients que sur le serveur CVS évite de devoir préciser le chemin d'accès au Repository à chaque exécution de commande CVS. Dans le cadre de cet article, cette variable a la valeur suivante :
sur les postes clients, on indique les identifiants de connexion : set CVSROOT=:pserver:userCVS:passwordCVS@MonServer:/CVSRepository avec:
sur le serveur CVS, en local donc, il suffit simplement d'indiquer le chemin complet d'accès au Repository: set CVSROOT=C:/CVSRepository |
Maintenant que cette variable d'environnement est créée, on peut accéder facilement et de la même façon à CVS aussi bien sur les postes clients que sur le serveur CVS. Il suffit par exemple de lancer la commande simple "cvs ls" sur le client ou le serveur pour obtenir le résultat escompté sans avoir à préciser l'option "-d" de CVS (je vous conseille d'ailleurs d'expérimenter un peu les commandes CVS pour vérifier que le variable CVSROOT est bien configurée pour votre contexte):
Avant de passer à Visual Studio .NET, il reste une petite configuration CVS à accomplir, qui consiste à lui spécifier les extensions de fichier qu'il doit considérer comme des fichiers binaires, de façon à ce que les commandes "cvs add" et "cvs import" fonctionnent correctement. Ce fichier s'appelle cvswrappers et se trouve dans le module CVSROOT (c'est-à-dire, donc, dans le sous-répertoire CVSROOT du Repository).
La marche à suivre consiste à mettre à jour ce fichier; comme il est sous contrôle de code source, il faut d'abord l'extraire avec CVS, appliquer les modifications puis l'archiver dans CVS :
1. se positionner dans un répertoire temporaire : cd C:\TEMP 2. effectuer l'extraction : cvs co CVSROOT 3. se placer dans le répertoire extrait : cd CVSROOT 4. ouvrir le fichierr cvswrappers dans un éditeur de texte et coller le texte suivant :
5. archiver le fichier : cvs commit |
CVS est maintenant complètement exploitable depuis les postes clients. Il nous reste à l'intégrer dans l'environnement de développement Visual Studio .NET 2003.
N'importe quel plug-in CVS SCC peut faire l'affaire (comme par exemple celui-ci), mais par souci de fiabilité et de professionnalisme nous allons porter notre choix sur un plug-in qui est payant, tout en n'étant pas cher (non, non, je ne touche aucune commission): il s'appelle "CVS SCC Proxy Plug-in" de la société PushOK. Le site où on peut le télécharger est le suivant : http://www.pushok.com/ (notez au passage qu'on peut aussi acquérir un plug-in pour Subversion sur le même site).
Il suffit de télécharger le plug-in puis de l'installer. Ensuite il faut lancer Visual Studio .NET 2003 et sélectionner le menu "Fichier/Contrôle de code source/PushOK CVS Proxy" :
Si votre licence PushOk n'est pas encore enregistrée, la fenêtre suivante s'affiche alors et vous invite à le faire :
Il s'agit ensuite de suivre la procédure d'enregistrement, c'est-à-dire de disposer d'une adresse e-mail valide qui fera office d'identifiant ainsi que de quelques dollars sur un compte par carte bleue avec accès sécurisé (24 dollars au moment de l'écriture de cet article). Notez bien qu'il faut une licence par poste de développement.
Le plug-in est prêt pour l'emploi : nous allons maintenant l'utiliser avec Visual Studio .NET.
Imaginons que nous ayons créé quelquepart sur notre machine une solution appelée "TestCVS" qui contient un projet C# appelé "ProgrammeTest"; ce projet est un exécutable en mode console dont le seul but est d'afficher la version applicative actuelle du programme :
Afin que cette solution soit sous contrôle de code source, nous allons l'intégrer dans le repository CVS, en tant donc que nouveau module CVS. Cela ne doit être fait qu'une seule fois par solution : une fois que ce module existera dans CVS, chaque développeur devra ensuite l'extraire depuis CVS et, ensuite, pourra travailler dessus de façon incrémentale.
Pour ajouter cette solution dans le Repository CVS, sélectionner le menu "Fichier/Contrôle de code source/Ajouter la solution au contrôle de code source" : une fenêtre s'affiche alors qui demande à saisir l'ensemble des données nécessaires à l'intégration dans CVS :
Dans l'écran suivant, remarquez que j'ajoute la solution directement depuis le serveur CVS, puisque ici CVSROOT utilise le protocole "local". Il est cependant conseillé de ne pas installer Visual Studio .NET sur le serveur CVS, car ce serveur devrait être uniquement destiné à faire du CVS et rien d'autre. On préfèrera donc ajouter la solution depuis n'importe quel poste client, et positionner la valeur CVSROOT qui correspond :
Il ne reste plus qu'à cliquer sur OK pour laisser faire Visual Studio .NET, qui par l'intermédiaire du plug-in PushOK va chercher à intégrer la solution au contrôle de code source correspondant, c'est-à-dire CVS. Le plug-in s'occupe donc bien de traduire des instructions Microsoft SCC en commandes CVS distantes, ce qui ne change pas des habitudes prises avec Visual Source Safe.
Une fois que Visual Studio .NET a ajouté la solution au contrôle de code source, on peut remarquer deux choses :
les fichiers sous contrôle de code source apparaissent maintenant avec un petit cadenas bleu dans l'explorateur de solutions, signe (comme l'infobulle le signale quand on passe la souris sur le cadenas) que les fichiers sont bien "archivés" dans CVS:
dans le répertoire du Repository sur le serveur CVS, la solution a bien été ajoutée sous la forme d'un répertoire dont la structure reprend exactement celle de la solution; localement, CVS créée également des répertoires de travail cachés, tous appelés "CVS".
Cette solution constitue donc maintenant la référence centralisée disponible pour tous les développeurs : ceux-ci vont devoir récupérer cette solution localement une fois, de façon à pouvoir travailler dessus.
Nous sommes donc dans la situation d'un développeur qui ne dispose pas encore de la copie locale d'une solution sous contrôle de code source. Pour télécharger entièrement la dernière version d'une solution sous contrôle de code source, il suffit de lancer Visual Studio .NET et de sélectionner le menu "Fichier/Contrôle de code source/Ouvrir à partir du contrôle de code source" :
On retrouve alors la fenêtre d'accès au Repository CVS:
la zone "CVSROOT" est à remplir comme précédemment
dans la zone "CVS MODULE" il faut spécifier le module existant dans CVS (éventuellement en cliquant sur le bouton "..." à droite de la zone de saisie du module)
surtout, dans la zone "LOCAL PATH", il faut indiquer le chemin complet du répertoire local dans lequel Visual Studio .NET va créer la solution à partir des fichiers du module CVS. Ici je vous conseille fortement de laisser faire Visual Studio qui, par défaut, propose un chemin local qui reprend le nom du module : il suffit juste d'ajouter un lecteur devant, par exemple C:\. Je reviendrai plus tard sur cette notion très importante de répertoire local. Notez juste qu'il faut bien vérifier ici le nom de ce répertoire, sous peine d'obtenir des résultats bizarres dans la structure des répertoires locaux...
On obtient donc quelque chose comme l'écran suivant :
Un simple clic sur le bouton "OK" achève la procédure, et recrée en local la structure des fichiers tels qu'ils étaient lors de la création de la solution. Le développeur peut maintenant travailler sur cette solution locale, comme s'il était tout seul.
Voilà, je suis un développeur et je dois apporter une modification capitale à la méthode Main() du programme de test. Je veux par exemple mettre en commentaires la ligne qui affiche "Ceci est la version 1.0" et ajouter une ligne qui affiche "Ceci est la version 1.1".
Comme les fichiers locaux sont en lecture seule, je dois d'abord extraire le fichier sur lequel je dois travailler : rien de plus simple, j'ai deux possibilités:
Dans les deux cas, une fenêtre me confirme ce que je suis en train de faire, et me propose de saisir un commentaire pour justifier de mon extraction (ces commentaires sont bien entendu accessibles via CVS, par l'historique des modifications qu'il conserve à chaque fichier):
Si je confirme en appuyant sur le bouton "Extraire", alors je peux apporter mes modifications au fichier, et je remarque aussi que maintenant le fichier est accompagné d'une petite coche rouge dans l'explorateur de solutions, signe qu'il a bien été extrait par moi :
Il s'est passé décidemment bien des choses car je remarque aussi qu'une fenêtre particulière, appelée "Archivages en attente", permet d'un seul coup d'oeil de connaître l'ensemble des extractions que j'ai réalisées jusqu'ici :
Imaginons maintenant que je me sois trompé et que, finalement, je n'ai plus envie d'apporter cette modification : je peux simplement annuler l'extraction avec un clic droit sur le fichier et en sélectionnant le menu "Annuler l'extraction..." : si j'ai déjà modifié le fichier Visual Studio .NET me prévient et me demande de confirmer ce que je suis en train de faire, c'est-à-dire un "undo" complet sur toutes mes modifications depuis le dernier archivage (comprenez bien que vous perdrez toutes vos modifications si vous acceptez) :
Bon, je n'ai pas à annuler l'extraction car je suis quand même très satisfait de mes brillantes modifications et je veux que tout le monde en profite. Pour mettre à jour mes modifications dans le référentiel CVS, j'ai là encore deux posssibilités :
soit je clique droit sur le fichier à archiver et je sélectionne le menu "Archiver..."
soit je clique directement sur le bouton "Archiver" de la fenêtre des archivages en attente, ce qui a le mérite d'archiver l'ensemble des fichiers que j'ai déjà extrait
Dans les deux cas, Visual Studio .NET procède à l'archivage et repositionne le petit cadenas bleu sur le fichier archivé. Il faut ici noter que pour mettre à jour le fichier, le plug-in Pushok effectue en fait deux phases :
d'abord un "cvs update" afin de récupérer les éventuelles modifications faites par un autre développeur sur le même fichier, afin de s'assurer qu'on fusionne bien les modifications. Cela permet donc à plusieurs développeurs d'opérer des modifications sur un même fichier source en même temps, sans pertes, du moment que ces modifications ne provoquent pas de "conflits" (voir plus loin)
puis un "cvs commit" pour valider le fichier dans CVS.
Si vous m'avez bien suivi jusque là, que se passe-t-il donc si, en même temps que j'ai modifié la fonction Main(), un autre développeur a ajouté une méthode Test dans ce même fichier Program.cs, juste après la méthode Main(), et a validé sa modification avant que je valide la mienne ? Comme par miracle, au moment où j'archive le fichier, celui-ci est mis à jour avec les modifications de l'autre développeur, et je vois alors apparaître toute seule la méthode Test() dans mon code :
Cela dit, pour cet autre développeur, comprenez bien qu'il ne voit pas encore mes modifications car il a archivé avant moi; pour cela il doit manuellement forcer une mise à jour de son fichier local, avec un clic droit sur le fichier et en sélectionnant le menu "Obtenir la dernière version". Concrètement, cela n'est pas nécessaire, car comme je l'ai dit Visual Studio .NET s'occupe d'activer cette fonction de façon transparente sur les fichiers modifiés qu'on cherche à archiver (par un "cvs update" préalable). Nous reviendrons un peu plus loin sur les cas où il est quand même préférable de forcer une mise à jour complète de l'ensemble des fichiers en local (donc, directement sur la solution elle-même).
L'ajout d'un projet dans une solution est extrèmement simple car tout repose sur le fonctionnement de Visual Studio lui-même:
Ajouter le projet dans la solution locale, comme d'habitude : cela provoque automatiquement l'extraction de la solution elle-même
Archiver les modifications depuis la fenêtre des archivages en attente
Les autres développeurs, pour voir le nouveau projet, devront alors activer le menu "Obtenir la dernière version (récursif)" sur la solution elle-même, ce qui aura pour effet de recréer le projet dans chaque solution locale.
La suppression d'un projet est à peine plus compliquée :
Supprimer le projet dans la solution locale, comme d'habitude : cela provoque automatiquement l'extraction de la solution elle-même. Noter que Visual Studio .NET ne supprime pas les fichiers dans le répertoire du projet.
Archiver les modifications depuis la fenêtre des archivages en attente
Supprimer manuellement les fichiers locaux du projet
Dans le répertoire sur le serveur CVS : supprimer aussi manuellement les fichiers du projet (en toute théorie on doit effectuer un "cvs remove" sur les fichiers à supprimer)
Les autres développeurs, pour ne plus voir l'ancien projet dans la solution, devront alors activer le menu "Obtenir la dernière version (récursif)" sur la solution elle-même. Ils devront alors supprimer manuellement les fichiers locaux du projet.
J'en viens maintenant à un point important: imaginons qu'un autre développeur ait déjà extrait un fichier et qu'il soit en train de modifier une ligne de code; je cherche moi aussi à vouloir extraire ce fichier pour modifier la même ligne de code (il s'agit ici d'un exemple typique qui ne devrait jamais arriver, dû à une mauvaise attribution des tâches ou à un mauvais découpage organique de l'application, mais dans les faits cela arrive malheureusement de temps à autre, notamment sur les assembly de classes communes à plusieurs projets).
Imaginons donc que je veuille changer à nouveau le numéro de version en "2.0", et que l'autre développeur veuille mettre "1.2". Regardons ce qui se passe alors :
dès l'extraction du fichier, Visual Studio .NET me prévient qu'il est déjà extrait par quelqu'un d'autre et me demande si je veux poursuivre; CVS, au contraire de Visual Source Safe, ne pose pas de lock sur les fichiers et autorise plusieurs développeurs à apporter des modifications de façon concurrente
l'autre développeur archive sa modification : dans CVS, la ligne de code est alors : "Console.WriteLine("Ceci est la version 1.2");"
je veux moi aussi archiver ensuite et mettre à la place : "Console.WriteLine("Ceci est la version 2.0");". Comme il n'a aucun moyen de savoir qui a raison à priori, car il s'agit juste d'un problème d'ordre dans les différents archivages concurrents, CVS détecte ce qu'on appelle un "conflit", et Visual Studio .NET affiche alors une fenêtre du genre WinDiff (paramétrable depuis les options de configuration du plug-in) qui montre à gauche ce que je veux archiver, et à droite ce qui est déjà dans CVS, avec une indication sur l'emplacement des conflits sous la forme de petits crochets jaunes :
Cet écran est en lecture seule : Visual Studio montre juste les conflits, il faudra les résoudre manuellement. Dès que je ferme cette fenêtre Visual Studio me demande si je veux continuer à archiver; si oui alors CVS considèrera que ce qui est à gauche constitue la dernière version du fichier, qui remplacera ce qui est à droite sans tenir compte de ce qui existe. L'autre développeur, s'il fait "Obtenir la dernière version" sur le fichier, verra donc "Console.WriteLine("Ceci est la version 2.0");" :
Vous voyez ainsi que le plug-in PushOK permet une intégration propre et complètement transparente de CVS dans l'environnement de développement Visual Studio .NET, et reproduit exactement le comportement de Visual Source Safe, en plus stable, rapide, et en autorisant les modifications concurrentes.
Voilà, c'est à peu près tout ce qu'il y a à savoir pour le développeur : avoir confiance dans CVS, et faire attention à ses extractions et à ses archivages. Avant de passer aux conseils pratiques, nous allons nous attarder sur le rôle joué par CVS dans un processus de build contrôlé par NAnt.
Si vous avez mis en place un processus de build basé sur NAnt, alors il y a de très fortes chances que vous ayez déjà un contrôle de code source activé. En fait il y a même fort à parier que ce soit CVS ! Pour ceux donc qui l'ignorent, NAnt permet d'intégrer CVS facilement, par exemple avec une tâche <exec> toute simple qui fait juste appel à la bonne commande CVS pour extraire dans un répertoire local connu de NAnt la dernière version de toute la solution qu'on désire compiler, ou bien directement la tâche <cvs> (comme toujours, on prendra soin bien sûr au préalable de faire le ménage parmi les sources déjà existantes, puisque de toutes façons on récupère tout) :
| <cvs command="checkout" destination="c:\TestCVS\" cvsroot="C:\CVSRepository" password="" module="TestCVS" /> |
L'intérêt est bien entendu de laisser le soin à NAnt de générer les exécutables de référence, en se basant sur la toute dernière version des sources. Mais je peux proposer d'aller un peu plus loin dans cette logique : NAnt est également disposé à automatiser :
la vérification de code source, avec FxCop par exemple
les tests unitaires, avec NUnit par exemple
la documentation de code source, avec NDoc par exemple
etc...
Il se trouve que chacun des logiciels que je cite peut utiliser des fichiers dits "de projet", qui servent à regrouper les références des fichiers qu'ils doivent manipuler en une seule entité :
FxCop utilise des projets de type "*.fxcop"
NUnit utilise des projets "*.nunit"
NDoc utilise des projets "*.NDoc
L'intérêt de ses projets est qu'ils peuvent également être mis sous contrôle de code source, afin que NAnt puisse en remonter la dernière version et, ainsi, dérouler par exemple les tests unitaires sur les dernières classes ajoutées à la solution. Une façon simple de faire consiste à ajouter ces fichiers en tant qu'élément existant dans la solution : en faisant cela, Visual Studio .NET les intègre en tant que "élements de la solution" et les place automatiquement sous contrôle de code source :
NAnt peut alors disposer de ces fichiers de projet à chaque fois qu'il procède à l'extraction complète de la solution. Bien entendu, il y a un petit désavantage : ces fichiers n'étant pas directement modifiables dans Visual Studio .NET, il faut les extraire manuellement, les modifier, puis les archiver en dehors de l'environnement de développement. Une autre façon de faire consiste à dérouler les tests unitaires sur l'ensemble des assembly générées par l'ensemble des sources, sans se soucier des fichiers de projet. L'important est de se rappeler que l'intégration de CVS dans un processus de build contrôlé par NAnt est un jeu d'enfant.
L'intégration de CVS dans Visual Studio .NET ainsi que dans le processus de build se réalisent donc très simplement et apportent des bénéfices immédiats considérables. Cela dit, l'expérience montre qu'il y a des conseils, et même des règles à respecter si on ne veut pas se retrouver confronté à des problèmes parfois un peu ardus à résoudre.
Voici quelques conseils et règles à bien respecter pour ne pas s'attirer d'ennuis avec le couple CVS / Visual Studio .NET :
A dire vrai, l'adoption d'un logiciel de contrôle de code source s'avère indispensable dans un cycle de développement logiciel moderne et sérieux. La facilité avec laquelle on peut exploiter CVS à travers Visual Studio .NET devrait encourager les réticents à faire le pas. Pour aller plus loin encore, je vous conseille de bien assimiler le formidable document suivant, qui traite de Visual Source Safe mais dont les principes sont valables ici aussi : Team Development.
Et si vous voulez aller plus loin avec CVSNT : http://www.fredshack.com/docs/cvsnt.html. Je vous encourage également à utiliser une des interfaces graphiques pour CVS, comme par exemple TortoiseCVS.
Bon courage et bonne chance dans vos pérégrinations avec CVS !
Le site officiel de CVSNT (téléchargements à droite de la page) : http://www.cvsnt.com/cvspro/
Un guide pour l'installation de CVS sous Windows : http://www.devguy.com/fp/cfgmgmt/cvs/cvs_admin_nt.htm
Le site officiel de SubVersion : http://subversion.tigris.org/
Le site de WinCVS : http://www.wincvs.org/
Le site de Pushok : http://www.pushok.com/
Un plug-in gratuit mais pas très stable ni fiable : http://www.jalindi.com/igloo/
Auteur : Laurent Desmons
Qui est Laurent ?
Laurent Desmons travaille
en environnement .NET pour le groupe GFI Informatique dans la région de
Aix-en-Provence. Il participe également depuis plusieurs années à
Copyright © Janvier 2005