|
Utilisation de CVS :
Les commandes CVS classiques :
Cette commande effectue un checkout distant. Elle récupère dans votre arborescence locale les modifications de fichiers et les fichiers dont vous ne disposez pas encore
Cette commande déclare à votre CVS local et au CVS distant l'existence d'un nouveau fichier. Cette commande s'effectue dans le répertoire qui contient le fichier.
Cette commande efface une déclaration de fichier. Après cette commande, vous devez effacer le fichier (rm file) puis faire un 'commit'.
Cette commande soumet une modification au serveur
CVS distant. Elle s'effectue dans le répertoire qui contient le fichier. Cas pratique 1.
Répercuter des modifications sur le serveur distant Lorsqu'un fichier a été modifié localement et que l'on se contente de lancer la commande :
cvs le rappelle par l'affichage d'un M
précédant le nom du fichier, mais ne met pas à jour cette modification sur le
dépôt.
L'option -z demande la compression des données transférées. Vous réduisez le temps de récupération des données.
Ou, le cas échéant :
pour mettre à jour sur le
référentiel l'ensemble des fichiers connus de cvs, et qui ont été modifiés dans
l'arborescence locale (plus généralement, le fait de ne pas spécifier
d'attribut après une instruction cvs implique que celle-ci sera exécutée
récursivement. cvs liste alors les fichiers dont les modifications viennent
d'être prises en compte. Il est possible de ne traiter que les fichiers du
répertoire courant, sans récursion, en ajoutant l'option -l).
Évidemment, si le fichier a été édité par un autre utilisateur et que ce dernier a validé ses modifications sur le référentiel tandis qu'on l'éditait localement, il y a problème. cvs rapporte alors le conflit. La plupart du temps, il suffira d'un :
pour que cvs fusionne
automagiquement les modifications dans le fichier local. Sauf si elles sont
trop imbriquées ou conflictuelles, auquel cas cvs invitera
pour que les modifications
soient finalement validées sur le référentiel. Afin d'éviter ce genre de
désagrément, mieux vaut effectuer de fréquentes mises à jour. 2. Ajouter et effacer un fichier Comme on l'a déjà remarqué, si un fichier
est édité localement, un simple checkout ne répercutera pas les modifications
sur le serveur. Il en va de même pour une création ou une suppression de
fichier. Ce comportement spontané s'avère d'ailleurs bien commode puisqu'il
dispense, par exemple, de devoir dupliquer des fichiers ou
cvs informe alors que la prise en compte du nouveau fichier ne sera effective qu'après le prochain commit :
De la même manière, la suppression d'un fichier ne sera effective qu'après le commit :
Enfin, s'agissant de la prise en compte de nouveaux éléments dans un projet, il ne faut pas perdre de vue que, destiné à conserver l'historique des versions, cvs s'attend par défaut à enregistrer des fichiers texte. Pour des raisons évidentes, les binaires ou archives (tar...) ne sauraient être traités de la même façon, et c'est pourquoi il faut alors indiquer leur nature « non historicisable » à cvs :
Ainsi, on évitera le plus souvent de placer sous le contrôle de CVS un fichier:
Utiliser des noms de répertoires au singulier, sans caractères spéciaux (ou accents, espaces ...), et sans majuscules sauf si l'une de ces caractéristiques est vraiment discriminante. La circulation s'en trouve facilitée. Exemple : test et non tests ou Test. Ces quelques commandes de base sont d'ores
et déjà suffisantes pour commencer à travailler avec cvs, dont la simplicité
n'est pas le moindre intérêt. 3. Suivre des modifications Cvs offre la possibilité de suivre
l'évolution d'un projet et, si nécessaire, de rebrousser chemin. Il est,
surtout, très utile de pouvoir remonter à la « source » d'un bogue, si celui-ci
n'est découvert qu'après l'édition de plusieurs nouvelles révisions.
Comme souvent, si un nom du fichier n'est pas précisé c'est l'ensemble des éléments du répertoire courant qui sera pris comme paramètre. Mais, même en indiquant un nom de fichier, la réponse de cvs peut être trop loquace si l'élément a connu de nombreuses modifications. Ainsi, il sera la plupart du temps judicieux de passer une indication temporelle en paramètre :
affichera le résumé des révisions postérieures au 1er avril 2000. La syntaxe autorise de multiples variantes. Attention toutefois à la notation « longue », car cvs ne semble pas comprendre le français. Voici quelques exemples :
La syntaxe paraît suffisamment explicite par elle-même. Sans doute n'est-il pas nécessaire de préciser que le dernier exemple liste les révisions intervenues entre deux périodes. Mais même si tout cela s'avère relativement intuitif, il faut parfois « ajuster » pour obtenir le résultat souhaité. En dernier recours, more ou less peuvent rendre des services équivalents. Une autre option particulièrement intéressante permet de limiter la sortie aux interventions d'un utilisateur particulier :
liste uniquement les
dates, numéros de révision et commentaires réalisés par l'utilisateur « nat ».
Mais ces commandes ne donnent pas encore accès au détail des
liste les différences entre la version locale d'un fichier et celle qui se trouve actuellement sur le référentiel, il apparaît aussi utile de pouvoir comparer le fichier actuel avec une révision antérieure particulière :
voire deux révisions intermédiaires, comme dans le second exemple. La sortie présentée par cvs ressemble à celle que produit l'utilitaire GNUdiff, et permet de visualiser ajouts, retraits et modifications. Il est d'ailleurs possible de stocker cette sortie sur disque au moyen d'un tube redirecteur, afin de traiter ensuite le fichier original (pour annulation de modifications, par exemple) avec l'utilitaire GNU diff. À noter que l'option -u, couramment utilisée avec l'utilitaire diff, est disponible avec la commande de cvs et produit le même type d'affichage. Une autre commande que l'on pourrait apparenter à diff affiche, ligne à ligne, le numéro de dernière révision, l'identifiant de son créateur/réviseur, et la date de la dernière modification, le tout en marge (à gauche) de l'information.
Contrairement à diff
annotate n'opère pas à proprement parler de comparaison entre deux versions,
mais produit une vision chronologique qui peut être pertinente, tant pour
estimer la part de nouveauté/persistance d'un fichier que pour « rendre à César
» telle ou telle partie....
Cette commande est utile
pour vérifier si un autre utilisateur n'a pas modifié et validé sur le dépôt un
fichier qu'on est en train d'éditer localement. Auquel cas (Needs Merge), il
faut s'attendre a devoir peut être gérer les conflits de version manuellement
lors du prochain commit... Le plus tôt sera le mieux, puisque, bien entendu,
les chances d'une résolution « automatique » des conflits s'amenuisent à mesure
que les divergences entre les deux copies s'accentuent. |