- articles

definition de skype: Par:Ichrak Ismail

2011-04-10T00:40:56+01:00

Le logiciel emploie une technologie innovatrice poste-à-poste, P2P (peer-to-peer), pour vous connecter avec les autres utilisateurs de Skype. Il suffit de télécharger l'application, de s'inscrire, et en quelques minutes à peine, vous pouvez brancher votre casque d'écoute et téléphoner à vos amis

Correction du rapport

2011-04-09T02:43:54+01:00

Organisé par Jarboui Lobna

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE

UNIVERSITE DE SOUSSE

المعهد العالي للإعلامية و تقنيات الاتصال بحمام سوسة

INSTITUT SUPERIEUR D’INFORMATIQUE

ET DES TECHNOLOGIES DE COMMUNICATION

HAMMAM SOUSSE

Spécialité : Mastère Professionnelle Service Multimédia et Web

THÈME :

Outils de gestions de version

Réalisé par : Encadré par :

Mlle Jarboui Lobna

Mlle Messoud Samar LILIA Cheniti

Mlle Ismail Ichrak

Mlle elarbi kawla

Année Universitaire 2010-2011

Sommaire

Introduction Générale. 1

1. Définitions: 1

1.1. Les versions : 1

1.2. La gestion de versions : 1

1.2.1. Le système de gestion de versions : 1

1.2.2. Utilité des systèmes de gestion de version : 2

2. Types de gestion de version : 2

2.1 Gestion de version centralisée : 2

2.2 Gestion de version décentralisée : 3

2.2.1. Avantages de la Gestion de version décentralisée : 4

2.2.2. Désavantages : 4

3. Logiciels de gestion de version : 5

3.1. Local : 6

3.2. Modèle client-serveur. 6

3.2.1. Libre : 6

3.2.2. Propriétaire : 6

3.3. Distribué : 7

3.3.1 Libre : 7

3.3.2 Propriétaire : 7

4 Logiciel de gestion de version centralisée « CVS » : 7

4.1. Définition : 7

4.2. CVS et le travail en groupe. 7

4.3 Succès et Limites. 8

4.4 Les commandes principales de CVS : 9

4.5 Utilisation du référentiel 14

4.6 Horloge système et synchronisation. 15

5 Logiciel de gestion de version décentralisée « Git » : 21

5.1. Principe de Fonctionnement de Git: 21

5.2. Démarrer un dépôt Git 22

5.2.1. Initialisation d'un dépôt Git dans un répertoire existant 22

5.2.2. Cloner un dépôt existant 22

5.3. Enregistrer des modifications dans le dépôt 23

5.3.1. Vérifier l'état des fichiers. 24

5.3.2 Placer de nouveaux fichiers sous suivi de version. 25

5.3.3. Indexer des fichiers modifiés. 25

5.3.4. Ignorer des fichiers. 26

5.3.5. Inspecter les modifications indexées et non indexées. 27

Conclusion Générale. 28

Introduction Générale

Grâce à l’hébergeur Source Forge, l’utilisation de systèmes de gestion de versions (VCS, Version Control System) en réseau s’est largement répandue et ces systèmes sont désormais un des principaux outils de travail collaboratif. En effet, plus faciles à utiliser et plus répandus, ces VCS sont utilisés par les développeurs bien sûr, mais aussi par les webmasters pour gérer les fichiers qui composent le site Web, par les ingénieurs système Unix pour gérer l’historique et par les auteurs de documentation ou de support de cours pour gérer leurs documents, articles ou exposés, etc.

1. Définitions:

1.1. Les versions :

Les logiciels évoluant, chaque étape d'avancement est appelée version. Les différentes versions sont nécessairement liées à travers des modifications. Les concepteurs du logiciel de gestion de versions RCS ont choisi de parler de « révisions » (revisions) afin de ne pas confondre la version du logiciel avec les « révisions » de ses fichiers sources.

1.2. La gestion de versions :

La gestion de versions (en anglais version control ou revision control) est une activité qui consiste à maintenir l'ensemble des versions ou révisions d'un logiciel ou autre document. Essentiellement utilisée dans le domaine de la création de logiciels. Elle est surtout concernée par le code source ; mais elle peut être utilisée pour tout type de document informatique.

1.2.1. Le système de gestion de versions :

Un système de gestion de versions (VCS) est un ensemble de logiciels qui va ajouter une nouvelle dimension au système de fichiers : le temps. Un système de fichiers traditionnel est organisé de manière hiérarchique, avec ses dossiers ou répertoires qui contiennent d’autres dossiers ou répertoires et finalement des fichiers. Le système de fichiers garde en outre trace des métadonnées, comme le nom du créateur du fichier, la date de création, . . .

Le VCS ajoute le temps : il garde trace de toutes les versions successives d’un fichier. Il peut afficher l’historique des modifications et récupérer une version quelconque d’un fichier. Cela permet, par exemple, de retrouver la dernière version stable, ou bien, si on a identifié la date d’apparition d’un problème, la modification effectuée à cette date là. Avec un VCS correct, il n’est plus nécessaire de « commenter » les bouts de code supprimés comme dans :

/* Removed on 2005-08-13: no longer

necessary. SB

if ((sigaction (SIGPIPE, &mysigaction, NULL))

< 0)

;

Il suffit de les supprimer et de noter dans l’historique la raison de cette suppression. Si cette dernière est regrettée, le VCS permettra de retrouver le code : rien ne disparait si on utilise un VCS. Le VCS stocke également des métadonnées comme le nom de l’auteur d’une modification. En effet, tous les VCS (comme les SGBD) permettent un accès partagé au système de fichiers versionné, et ce sont donc de véritables outils de travail en groupe.

1.2.2. Utilité des systèmes de gestion de version :

ü Accès concurrentiel par plusieurs développeurs

ü Suivi de l’historique

ü Visualisation des déférences

ü Retour à des anciennes versions

2. Types de gestion de version :

2.1 Gestion de version centralisée :

Dans les systèmes centralisés, il y a un dépôt de référence et les utilisateurs lisent et écrivent uniquement dans ce dépôt. Cela simplifie la gestion des versions mais est contraignant pour certains usages (travail sans connexion au réseau ou tout simplement travail sur des branches expérimentales ou contestées).

CVS est l’archétype de ces VCS. Mais désormais, sur ce créneau, il cède du terrain à Subversion. Ce dernier, baptisé « CVS++ », tente de faire « CVS sans les problèmes ». Par exemple, il permet enfin de renommer un fichier. Ou de « versionner » les méta-données.

Subversion est donc composée d’un dépôt unique sur un serveur où se trouve l’ensemble des fichiers, de leurs versions ainsi que des branches qui permettent de gérer plusieurs versions du projet en parallèle.

Les développeurs (Alice et Bob par exemple) récupèrent une version du projet sur leur poste de travail (avec la commande check out) pour pouvoir commencer à travailler dessus. Au quotidien, ils mettent à jour leur copie de travail local (update) depuis le serveur Subversion et renvoient leurs modifications (commit) vers ce même serveur. Ce mode de fonctionnement permet aux développeurs de travailler en parallèle sur le projet, de partager leurs modifications et de versionner les fichiers qu’ils modifient.

Figure 1 : le principe de fonctionnement de logiciel centralisé

Peu adapté aux grands effectifs.
Haute disponibilité du serveur contenant le dépôt nécessaire.
Infrastructure requise pour mettre en place un dépôt commun.
Moins d'organisation humaine requise vu qu'il n'y a qu'un seul dépôt.
Ne peut pas être distribué.
Plus facile a prendre en main : les étapes pour un cycle de développement sont moindre.

Utilisez un système centralisé pour une petite équipe rigoureuse pouvant être connectée au serveur en permanence et ne pouvant pas se permettre de passer du temps quant à l'organisation pour fusionner les dépôts.

2.2 Gestion de version décentralisée :

Avec l'arrivée des logiciels libres et leur développement communautaire, une autre façon de voir la gestion de versions est apparue. Cette autre vision consiste à voir l'outil de gestion de versions comme un outil permettant à chacun de travailler à son rythme, de façon désynchronisée des autres, puis d'offrir un moyen à ces développeurs de s'échanger leur travaux respectifs. C'est ce que l'on nomme la gestion de versions décentralisée.

Lorsqu’on parle de gestion de version distribuée, cela signifie que le dépôt de fichier n’est plus unique sur un serveur mais que chaque développeur possède son propre dépôt. Chacun de ces dépôts contient l’ensemble des versions des fichiers. C’est de ce principe que découle toutes les autres fonctionnalités d’outils comme Git, Mercurial ou encore Bazaar. Pour illustrer cet article, les exemples s’appuieront sur Git. Même s’ils diffèrent dans le détail, les principes de dépôts multiples et d’échange entre ces dépôts restent globalement les mêmes pour chacun de ces outils.

Dans les systèmes décentralisés, on essaie de mieux coller au mode de développement en réseau si fréquent dans le logiciel libre. Dans ces VCS, il n’y a plus de dépôt de référence. Plusieurs dépôts coexistent et on peut lire et écrire dans celui de son choix. Cela met fin au dépôt central sacré, avec ses « commiteurs » privilégiés qui regardent les autres de haut. Le fait d’accorder ou de refuser le droit de « commiter » entraine souvent des crises qui sont désormais inutiles. La décentralisation permet plus facilement de suivre un logiciel amont, auquel on ajoute quelques patches qui ne seront pas forcément intégrés.

Les VCS décentralisés dédramatisent ainsi le fork, la scission, qui a secoué tant de projet de logiciel libre, en le rendant moins radical et moins définitif. Elle permet enfin un travail avec le VCS en mode déconnecté, ce qui est important compte tenu de l’explosion de l’utilisation des ordinateurs portables (le portable contient un vrai dépôt)

Mercurial, Darcs, Bazaar, Git, Monotone, GNU Arch et BitKeeper (propriétaire) sont des logiciels de gestion de versions décentralisée. Avec ceux-ci, il existe plusieurs dépôts de versions et aucun n'a de statut privilégié.

2.2.1. Avantages de la Gestion de version décentralisée :

ü Permet aux contributeurs de travailler sans être connecté au gestionnaire de version,

ü La plupart des opérations sont plus rapides car réalisée en local (sans accès réseau),

ü Permet la participation à un projet sans nécessiter les permissions par un responsable du projet (les droits de commit peuvent donc être donnés après avoir démontré son travail et non pas avant),

ü Permet le travail privé pour réaliser des brouillons sans devoir publier ses modifications et gêner les autres contributeurs,

ü Permet de ne pas être dépendant d'une seule machine comme point de défaillance,

ü Permet toutefois de garder un dépôt de référence contenant les versions livrées d'un projet

2.2.2. Désavantages :

ü Cloner un dépôt est plus long que récupérer une version pour une gestion de version décentralisée car tout l'historique est copié (ce qui est toutefois un avantage par la suite).

ü Il n'y a pas de système de lock (ce qui peut poser des problèmes pour des données binaires qui ne se mergent pas)

ü Adapté aux grands effectifs.

ü Pas de contrainte de disponibilité du serveur.

ü Risques réduits pour l'intégrité du dépôt final.

ü Pas de contrainte d'infrastructure car il n'y a pas nécessité d'avoir un dépôt commun.

ü Peut être centralisé, mais demande plus d'organisation humaine pour fusionner les différents dépôts dans un dépôt commun.

ü Plus difficile à prendre en main de part les possibilités et les étapes nécessaires a un cycle de développement.

Utilisez un système distribué pour une équipe aussi bien petite que grande, possédant la rigueur nécessaire à une hiérarchisation des dépôts et/ou ayant des contraintes de travail ne permettant pas d'être connectée en permanence avec un éventuel serveur.

L'auteur de développement logiciel Joel Spolsky décrit la gestion de version décentralisée comme "probablement la plus grande avancée dans les technologies de développement logiciel dans les 10 [dernières] années."

3. Logiciels de gestion de version :

Un logiciel de gestion de versions agit sur une arborescence de fichiers afin de conserver toutes les versions des fichiers, ainsi que les différences entre les fichiers.

Ce système permet par exemple de mutualiser un développement. Un groupe de développeurs autour d'un même développement se servira de l'outil pour stocker toute évolution du code source. Le système gère les mises à jour des sources pour chaque développeur, conserve une trace de chaque changement. Ceux-ci sont, en bonne utilisation, chaque fois accompagnés d'un commentaire. Le système travaille par fusion de copies locale et distante, et non par écrasement de la version distante par la version locale. Ainsi, deux développeurs travaillant de concert sur une même source, les changements du premier à soumettre son travail ne seront pas perdus lorsque le second, qui a donc travaillé sur une version non encore modifiée par le premier, renvoie ses modifications.

Généralement, chaque nouvelle version d'un fichier est appelée révision et son numéro de version est incrémentée de 1 par rapport à la précédente

À cet effet, il existe différents logiciels de gestion de versions qui, bien qu'ayant des concepts essentiels communs, apportent chacun son propre vocabulaire et ses propres usages. On peut les classée comme suit :

3.1.Local :

Libre :

GNU RCS
SCCS

3.2. Modèle client-serveur

3.2.1. Libre :

ü CVS

ü JediVCS, http://jedivcs.sourceforge.net/

ü MECASP, gestion de versions et fusion (En physique et en métallurgie, la fusion est le passage d'un corps de l'état solide vers l'état liquide. Pour un corps pur, c’est-à-dire pour une substance constituée de molécules toutes identiques, la fusion s'effectue à température constante. La température de fusion ou de solidification d'un...) de variantes : http://mecasp.free.fr

ü So6 : logiciel de gestion de configuration (La gestion de configuration consiste à gérer la description technique d'un système (et de ses divers composants), ainsi qu'à gérer l'ensemble des modifications apportées au cours de l'évolution du système. La gestion de configuration est utilisée pour la gestion de systèmes complexes :) de LibreSource

ü Subversion (SVN) : http://subversion.tigris.org

3.2.2. Propriétaire :

ü Dimensions CM (Serena Software)

ü ALDON Lifecycle Manager (ALDON): http://www.aldon.fr ClearCase (Rational Software/IBM)

ü IBM Rational Team Concert (Rational Software/IBM)

ü MKS Integrity: http://www.mks.com/

ü Perforce

ü SCM Surround (Société Seapine)

ü IBM Rational Synergy

ü Vault (SourceGear)

ü Visual SourceSafe (Microsoft)

ü Microsoft Visual Studio Application Lifecycle Management

ü Team Foundation Server (Microsoft)

3.3. Distribué :

3.3.1 Libre :

ü Bazaar : compatible avec GNU Arch et son lointain descendant Bazaar-ng : http://bazaar.canonical.com (compatible avec GNU Arch) et son lointain descendant Bazaar-ng : http://www.bazaar-ng.org

ü darcs : http://www.darcs.net/

ü Fossil

ü git : utilisé entre autres pour le noyau GNU/linux

ü GNU Arch: http://www.gnu.org/software/gnu-arch/

ü Mercurial : http://www.selenic.com/mercurial

ü Monotone

ü PVCS (Serena Software): http://www.serena.com/

ü SVK, basé sur le système de fichier de Subversion : http://svk.elixus.org/

3.3.2 Propriétaire :

ü BitKeeper

ü ClearCase, multiSite (Rational Software/IBM)

Le concept des gestions de versions peut s'adapter à d'autres types de ressources. Les Wikis (tel que Wikipédia) sont des exemples de logiciels de gestion de versions agissant sur des champs de base de données et non sur des fichiers.

Des logiciels comme Tailor permettent en outre d'effectuer des conversions entre les formats d'archive des différents logiciels de contrôle de version.

4 Logiciel de gestion de version centralisée « CVS » :

4.1. Définition :

CVS ( acronyme de Concurrent Versions System), est un système de gestion de versions c’est un logiciel libre, successeur de SCCS, Puisque ce logiciel aide les sources à converger vers la même destination, on dira que CVS fait la gestion concurrente de versions ou de la gestion de versions concurrentes. Il peut aussi bien fonctionner en mode ligne de commande qu'à travers une interface graphique. Il se compose de modules clients et d'un ou plusieurs modules serveur pour les zones d'échanges.

Le modèle de CVS est un modèle centralisé, où un serveur central regroupe toutes les sources,

4.2. CVS et le travail en groupe

On peut résumer les services de CVS en 4 grands besoins :

ü Travailler à plusieurs sur les mêmes fichiers au même moment ;

ü Gérer les versions des fichiers en cours de rédaction ;

ü Suivre les versions de documents externes ;

ü gérer plusieurs branches de développement.

Pour cela CVS utilise une zone de stockage spécifique appelé référentiel, dans

lequel sont stockées toutes les données nécessaires au fonctionnement et suffisante

pour retrouver toutes les données qui lui ont été confiées. Il fait aussi un grand usage des ressources du système, comme la notion d’utilisateurs multiples, la structure arborescente des fichiers, et les possibilités client/serveur. C’est pourquoi ces fonctions-là ne seront pas détaillées.

4.3 Succès et Limites

CVS a mérité cette place en fournissant un outil de travail en groupe souple et riche à beaucoup de développeurs. CVS a popularisé l’idée de non-réservation d’un fichier : tout développeur muni des droits appropriés peut éditer un fichier. Si deux développeurs essaient d’enregistrer le même fichier, CVS tente de fusionner les deux modifications. S’il échoue, ce qui arrive par exemple si les deux modifications sont situées sur la même ligne du fichier, il affichera un conflit, qu’il laissera les développeurs résoudre

Avant CVS, il était courant d’avoir des VCS qui obligeaient à effectuer une réservation préalable d’un fichier qu’on voulait éditer. Par oubli ou par volonté de garder le contrôle, beaucoup d’auteurs oubliaient de terminer cette réservation et le fichier devenait non modifiable. Mais avec le temps, CVS n’a pas évolué et ses limites semblent maintenant de moins en moins acceptables :

1. Les commits, ou enregistrements des modifications, ne sont pas atomiques. En cas de disque plein, par exemple, on peut ne commiter qu’une partie des fichiers. La raison fondamentale est que CVS gère des fichiers,pas des patches. Nous verrons que tous les outils ultérieurs considèrent que l’objet élémentaire est le,patch, pas le fichier.

2. CVS ne connait pas le renommage d’un fichier : si on change un fichier de nom, on perd tout l’historique de ce fichier.

3. Le travail sur du code tiers, ou bien les expérimentations sur le code sont pénibles car ce qui permet ces travaux en parallèle, les branches, sont lentes et difficiles d’usage.

4. Les répertoires ne sont pas versionnés (un répertoire est juste un container6),

5. les méta-données ne sont pas versionnées : on ne peut pas attacher de propriétés (comme les permissions) à un fichier, par exemple.

6. Il n’y a guère de travail possible lorsqu’on est déconnecté du réseau (cas d’un portable). Même cvs diff demande un accès au réseau.

# Alice a fini sa première version

alice> cvs add article.db

alice> cvs commit -m "Premiere version" article.db

# Bob récupère les changements

bob> cvs update

# Il effectue des modifications puis :

bob> cvs commit -m "Meilleure explication des causes de panne" article.db

# Alice récupère les changements

alice> cvs update

# Qu’a fait Bob, exactement ?

alice> cvs diff -r1.1 -r 1.2 article.db

Exemple 1 – Alice et Bob travaillent ensemble grâce à CVS

7. Enfin, le code, peu clair et pas documenté, n’est plus du tout maintenu.

4.4 Les commandes principales de CVS :

§ cvs login (pour se connecter en mode client server)

§ cvs logout (pour se déconnecter en mode client server)

§ cvs import -m "Liste nouveaux composants" nom_projet/HOWTO LFO V1 (ajoute les fichiers du répertoire courant avec le vendeur-tag LFO et le release-tag V1, sans avoir de copie de travail et évite de recourir aux sous-commandes add et commit pour tous les fichiers et répertoires ajoutés)

§ cvs checkout nom_projet (récupère en local le module nom_projet)

§ cvs update (met à jour les fichiers de la copie de travail en local)

§ cvs status -v nom_fichier (visualise l'état et les noms de versions symboliques du fichier)

§ cvs -n update (idem que cvs status mais les informations sont plus condensées)

§ cvs add -m (ajout de la procédure d'installation" INSTALL, ajoute le fichier INSTALL)

§ cvs remove -f nom_fichier (supprime physiquement et dans la base CVS nom_fichier), pour être validée cette commande devra être suivie d'un cvs commit

§ cvs commit -m "première version" index.html (archive la version dans CVS

§ cvs export -k v -d version_prod -r STABLE-V1_1 nom_projet (extrait une copie du module nom_projet dans le répertoire projet_v1_1 sans les répertoires de gestion utilisés par CVS)

§ cd nom_projet/srv_server & cvs tag SRV-V1_0 (défini le nom symbolique SRV-V1_0 pour tous les fichiers de nom_projet/srv_server)

§ cvs co -r SRV-V1_0 nom_projet/srv_server (récupère les fichiers ayant le tag SRV-V1_0 de nom_projet/srv_server)

§ cvs rtag SRV-V2_0 nom_projet (défini le nom symbolique SRV-V2_0 à la dernière version présente dans la base des fichiers du module nom_projet)

§ cvs diff --ifdef=V1_2 -r1.1 -r1.3 index.html (affiche les différences entre les versions 1.1 et 1.3 en séparant les modifications par le symbole préprocesseur V1_2)

§ cvs rdiff -s -r STABLE-V1_0 nom_projet (résume les différences entre la version STABLE-V1_0 et la dernière version en base)

§ cvs rdiff -u -r STABLE-V1_0 nom_projet (visualise les différences)

§ cvs release -d nom_projet (vérifie que toutes vos modifications sont archivées et indique à CVS que vous n'utilisez plus votre copie de travail)

EXemple :

Release : Supprimer proprement son espace de travail

On peut faire autant de checkouts qu'on veut, et parfois on se retrouve avec beaucoup d'espaces de travail qui ne servent plus. Mais avant de supprimer un tel répertoire, il faut faire attention à ne pas perdre de travail. La commande suivante vérifie si le répertoire ne contient pas de travaux non sauvegardés :

$ cvs release monprojet

Un résumé des éventuelles différences avec le repository apparaît. Si aucune de celles-ci n'est intéressante, supprimer le répertoire.

Renommer ou déplacer un répertoire ou un fichier

On ne peut pas. C'est une limitation conceptuelle de CVS. Il faut supprimer puis recréer. Dans le cas d'un répertoire à renommer, il faut créer un nouveau répertoire et déplacer les fichiers qui s'y trouvaient. Il ne faut pas supprimer l'ancien répertoire, sous peine de perdre son historique, donc de perdre les versions antérieures ! Ce n'est pas grave de garder ce répertoire car s’il est vide il ne sera pas créé lors des checkouts suivants.

Consulter une vieille version d’un fichier

Restaurer une version précédente d’un fichier

En principe, on n'a jamais besoin de le faire, mais ça peut arriver de vouloir annuler les modifications du dernier ou des derniers commit. Dans ce cas, bien identifier la version à restaurer et taper les commandes :

$ cvs -Q update -p -r 1.14 fichier.c > fichier.c

$ cvs commit fichier.c

Ressusciter un fichier supprimé du repository

Après un « cvs rm -f fichier.c » un peu trop expéditif, on peut toujours faire renaître le fichier, dans le repository et dans son répertoire local. Il faut se souvenir du nom et de l'emplacement du fichier. Dans le répertoire où il se trouvait, taper la commande suivante :

$ cvs status fichier.c

Bien qu'il n'existe plus localement, cvs nous donne l'identifiant de la dernière version du fichier sur le tronc commun :

$ File: no file fichier.c          Status: Up-to-date

$    Working revision:  No entry for fichier.c

$    Repository revision:       1.6     /tests/proj/d/Attic/fichier.c,v

L'information que nous recherchons est « Repository revision », qui a ici pour valeur « 1.6 ». Utiliser cette valeur dans l'incantation suivante :

$ cvs -Q update -p -r 1.6 fichier.c > fichier.c

Le fichier est maintenant dans le répertoire local. Il ne reste plus qu'à l'ajouter et le "commit"er vers le repository :

$ cvs add fichier.c

$ cvs commit

Dans le commentaire du commit, il peut être bon de placer la phrase « Resurrected from 1.6 » pour se rappeler d'où ça vient.

History :Voir les dernières actions effectuées sur le repository

Quelqu'un a "commité" du code faux, et ça ne compile pas ? Pour connaître le nom du coupable, utilisez la commande suivante qui donne les liste des modifications sur le repository pendant les 3 derniers jours :

$ cvs history -ca -D "3 days ago"

Cette commande donne toutes les opérations de lecture/écriture sur le repository pour le module monprojet :

$ cvs history ae -m monprojet

Diff : difference entre un fichier local et sa version du repository

On peut parfois oublier quelles modifications on a apporté à un fichier depuis le dernier commit. Pour connaître les différences entre sa version locale modifiée et la version du repository, on peut utiliser la commande suivante :

$ cvs diff fichier.c

Voir les différences entre plusieurs versions d’un fichier

$ cvs diff -r revision1 -r revision2 fichier

Restaurer le version du repository pour un fichier

Après avoir fait des tests en modifiant un fichier, on peut vouloir annuler ces modifications. Pour revenir à la version du repository, sans prendre en compte les modifications, il faut d'abord effacer le fichier local, puis l'updater :

$ rm fichier.c

$ cvs update fichier.c

Import : Intégrer un projet dans CVS

Nettoyer les fichiers temporaires.
Bien identifier les parties qui sont communes à plusieurs projets pour définir les modules. Dans le cas d'un projet de petite taille, tout peut aller dans un seul module.
Pour chaque module:
1. Se mettre dans le répertoire où sont les sources et répertoires.
2. Taper : “cvs import d1 d2”. d1 et d2 sont des textes bidons, utiles seulement dans des cas particuliers.
3. Remonter d'un répertoire, et renommer le répertoire dans lequel on était avec un nom qui fasse comprendre qu'on ne doit plus y toucher (exemple: monprojet.original). Éventuellement le mettre en lecture seule.
Créer d'éventuels alias de modules.
Et voilà. Pour commencer à travailler, il ne reste plus aux développeurs qu'à faire un checkout.

Aller voir ce qui se trouve dans le repository

Il est possible d'aller consulter directement le repository, mais les fichiers y sont stockés dans un format spécifique. Le plus simple et le plus confortable est de naviguer en utilisant par exemple le logiciel CvsWeb [archive]. Attention: On pourrait parfois être tenté de modifier directement le repository global. Il n'y a jamais besoin de le faire ! Ce serait un moyen très facile de perdre tout l'historique, ce qui aurait notamment pour conséquence l'impossibilité de faire des corrections dans les versions releasées.

Tag : Marquer des versions de fichiers

Il est parfois utile de marquer une version particulière d'un ou plusieurs fichiers, par exemple pour marquer le périmètre d'une amélioration. Par exemple, si je viens d'améliorer fichier1.c et fichier2.c pour corriger le bug BUG_6845, il peut être judicieux de taper la commande : cvs tag BUG_6845 fichier1.c fichier2.c S’il s'agit de tagger toute une arborescence, utiliser dans la commande : cvs rtag BUG_6845 monprojet

Tag -b: Créer une branche

Créer une branche MONPROJET_7_1_1_1 permet, plus tard, de récupérer cette version livrée en faisant un checkout avec l'option “-r”. Rien n'est dupliqué dans le repository, cette commande ajoute simplement un tag à tous les fichiers dans l'état où ils sont. Il faut d'abord se mettre dans son répertoire de développement, faire un cvs update pour vérifier que tout est à jour :

$ cvs update

Vérifier une dernière fois que tout est ok, packager le logiciel, faire la sortie officielle de cette version, puis tagger avec l'option -b :

$ cvs tag MONPROJET_7_1_1_1-trunk

$ cvs tag -b MONPROJET_7_1_1_1

Ensuite, les développeurs qui le souhaitent pourront travailler séparément sur le tronc commun, ou sur la branche. Cette commande crée deux espaces de travail, un pour la version de développement et un pour la version livrée 7.1.1.1 :

$ cvs checkout monprojet

$ mv monprojet monprojet_dev

$ cvs checkout -r MONPROJET_7_1_1_1 monprojet

$ mv monprojet monprojet_7111

Le tag MONPROJET_7_1_1_1-trunk n'est généralement pas utile, mais on peut en avoir besoin dans la situation bien particulière où on voudrait récupérer l'image du tronc commun tel qu'il était au moment de la création de la branche.

Reporter les améliorations d’une branche vers le tranc

Tout d'abord, se mettre dans une copie locale de la branche et tagger les fichiers dans lesquels se trouvent les améliorations (ou tout si c'est justifié) :

branche$ cvs tag mergeto_trunk_FIX1016 fichiers ...

Convention: J'ai pris l'exemple de FIX1016 mais on peut prendre n'importe quel identifiant qui soit unique au repository entier. Se mettre dans une copie locale du tronc et lancer cette commande :

tronc$ cvs update -j mergeto_trunk_FIX1016

Il y aura probablement de nombreux conflits à résoudre. Une fois que c'est fait, commiter et tagger:

tronc$ cvs commit fichiers ...

tronc$ cvs tag mergefrom_DEL_CAS_7_1_1_1_FIX1016 fichiers ...

MONPROJET_7_1_1_1 est un exemple qui correspond au nom exact de la branche.

Reporter les améliorations du tronc vers une branche

Tout d'abord, se mettre dans une copie locale du tronc et tagger les fichiers dans lesquels se trouvent les améliorations (ou tout si c'est justifié) :

tronc$ cvs tag mergeto_MONPROJET_7_1_1_1_AMELIORATION756 fichiers ...

Se mettre dans une copie locale de la branche et lancer cette commande :

branche$ cvs update -j mergeto_DEL_CAS_7_1_1_1_AMELIORATION756

Il y aura probablement de nombreux conflits à résoudre. Une fois que c'est fait, commiter et tagger:

branche$ cvs commit fichiers ...

branche$ cvs tag mergefrom_trunk_AMELIORATION1016 fichiers ...

4.5 Utilisation du référentiel

Un référentiel CVS est un agrégat d’objets ayant chacun leur version. L’évolutiondes objets et de leurs versions se fait par :

v Extraction du référentiel (checkout/update)

v modification en environnement de travail standard ;

v repose dans le référentiel pour mise à jour (commit).

On dit que CVS utilise un modèle par composition. Pour la gestion de la concurrence,il s’inspire du modèle des transactions longues, qui a la caractéristique desupporter autant de divergences que possible entre les différentes versions, la seulecontrainte de cohérence étant exigée au moment de la réunification des versions.

Autrement dit une session de travail avec CVS peut se résumer ainsi :

1. cvs update : Je synchronise ma copie de travail avec le référentiel. CVS me

signale les mises à jour.

2. à la fin de ma session, je valide mon travail. CVS me confirme si mes modifications

sont compatibles avec les autres travaux en cours.

3. si elles ne le sont pas, j’ai le choix de conserver mon autonomie ; je ne profiterai

plus des mises à jour concernant cet objet. Ce choix se répercutera sur les tentatives

de mises à jour futures (warning), à moins que je ne crée ma propre branche de développement.

4. si je choisis la dissidence, et que je veux en faire profiter les autres, je dois créerune nouvelle branche.

Chaque transaction est enregistrée et peut faire l’objet d’une action (envoi d’unmessage électronique à l’équipe de développement :

v pour chacun de connaitre l’historique des actions et en particulier des modifications apportées à chaque objet 8

v pour l’administrateur de savoir qui en est où.

Remarque :

Il est courant d’ajuster les droits pour mettre tous les développeursà égalité. En revanche, il ne peut y avoir à tout moment qu’une branche principale,chaque branche pouvant reprendre ce titre sur commande, d’où le besoin d’une certaineconcertation dans l’équipe.

4.6 Horloge système et synchronisation

L'horloge du serveur et toutes les machines clientes devront être synchronisées à l'aide de Network Time Protocol (un protocole qui permet de synchroniser via un réseau informatique, l'horloge locale d'ordinateurs sur une référence d'heure), en effet CVS se sert de l'heure et de la date pour effectuer ses opérations et cela est capital pour l'intégrité de la base CVS. En effet le serveur CVS effectuant des comparaisons entre les différentes versions du fichier, des écarts de dates entre les différents postes, mettront en péril l'intégrité de la base CVS.

Le dépôt (repository)

Le dépôt est la base centralisée de CVS à savoir les fichiers d'administration se trouvant dans le sous dossier CVSROOT ainsi que les dossiers des différents projets (livres, développements, sites web, ...). Ce répertoire peut se trouver n'importe où sur le système de fichiers (ex: /usr/local/cvsroot) et le chemin pour l'atteindre doit être défini dans la variable d'environnement $CVSROOT. Afin que chaque utilisateur d'un groupe de travail puisse travailler sur un projet, le dossier ($CVSROOT/nom_projet) devra avoir les droits en lecture et écriture sur le groupe ainsi que le bit s positionné (garanti que chaque fichier/dossier cré appartient au groupe), il en sera de même pour /var/lock/cvs/nom_projet.

Initialisation du dépôt

Dans le cas on installe CVS pour la première fois, ou qu’on n’a pas de dépôt. Une fois la variable d'environnement CVSROOT définie, sur le serveur, on lance la commande :

mkdir /usr/local/cvsroot

cvs init

Ou pour plus de contrôle sur la création du dépôt :

cvs -d /usr/local/cvsroot init

chown -R cvs:cvs /usr/local/cvsroot

chmod g+rwxs /usr/local/cvsroot/CVSROOT

Pour les accès en mode connecté, vous devrez ensuite créer le fichier $CVSROOT/CVSROOT/passwd ayant la structure suivantelogin_CVS:[mot_de_passe_crypt][:login_systeme]

Ce fichier étant particulièrement sensible il est préférable de ne pas mettre les mêmes mots de passe que ceux pour se connecter au serveur et de donner les droit suivants au fichier passwd de cvs.

chmod 400 $CVSROOT/CVSROOT/passwd

C’est un des rares cas où vous irez modifier un fichier dans $CVSROOT/CVSROOT. L'accès se fait par l'utilisation des commandes CVS.

Configuration du serveur CVS

Accédez au serveur avec un utilisateur faisant partie du groupe cvs.

mkdir ~/Projets/

cd ~/Projets/

cvs -d /usr/local/cvsroot checkout CVSROOT

si la variable CVSROOT est définie l'option -d /usr/local/cvsroot est facultative

-rw-rw-r-- 1 jmj jmj 495 mai 17 01:49 checkoutlist

-rw-rw-r-- 1 jmj jmj 760 mai 17 01:49 commitinfo

-rw-rw-r-- 1 jmj jmj 986 mai 17 02:35 config

drwxr-xr-x 2 jmj jmj 4096 mai 23 19:01 CVS/

-rw-rw-r-- 1 jmj jmj 602 mai 17 01:49 cvswrappers

-rw-rw-r-- 1 jmj jmj 1025 mai 17 01:49 editinfo

-rw-rw-r-- 1 jmj jmj 1141 mai 17 01:49 loginfo

-rw-rw-r-- 1 jmj jmj 1151 mai 17 01:49 modules

-rw-rw-r-- 1 jmj jmj 564 mai 17 01:49 notify

-rw-rw-r-- 1 jmj jmj 649 mai 17 01:49 rcsinfo

-rw-rw-r-- 1 jmj jmj 879 mai 17 01:49 taginfo

-rw-rw-r-- 1 jmj jmj 1026 mai 17 01:49 verifymsg

Modifiez le fichier config :

cd CVSROOT

vi config

# Exemple de fichier config

SystemAuth=no

LockDir=/var/lock/cvs

TopLevelAdmin=no

LogHistory=TOEFWUPCGMAR

RereadLogAfterVerify=always

Validez les modifications

cvs commit -m "Configuration initiale de CVS" config

Accès au dépôt

L'accès à cette base CVS peut s'effectuer de 5 manières différentes:

1. Direct

Les fichiers dans ce cas doivent être accessible directement au travers du système de fichier ou d'un système de fichier réparti tel que NFS ou SMB. Dans ce cas nous utilisons CVS en mode non connecté.

CVSROOT=:local:/usr/local/cvsroot ou CVSROOT=/usr/local/cvsroot

2. Serveur

Le serveur CVS est en attente des requêtes clientes, sur le port TCP 2401. A ajouter dans /etc/services:

cvspserver 2401/tcp # CVS client/server operations dans /etc/inetd.conf si vous utilisez inetd

cvspserver stream tcp nowait cvs /usr/bin/cvs cvs –allow root=/usr/local /cvsroot pserver

Pour qu'inetd prenne en compte les changements dans son fichier de configuration

killall -HUP inetd

Si vous utilisez xinetd

# CVS configuration for xinetd don't forget to specify your CVSROOT in

# /etc/cvs/cvs.conf.

service cvspserver

{

disable = no

socket_type = stream

protocol = tcp

wait = no

user = root

passenv = PATH

server = /usr/sbin/cvspserver

server_args = -f --allow-root=/usr/local/cvsroot pserver

}

Pour que xinetd prenne en compte les changements :

killall -HUP xinetd

Sur la machine cliente définir la variable CVSROOT

CVSROOT=:pserver:user@server:/usr/local/cvsroot

L'authentification est réalisée grâce à la commande :

cvs login :qui enregistrera le mot de passe sous forme chiffrée dans le fichier .cvspass si la connexion est acceptée (pour changer le nom du fichier.cvspass, définissez le dans $CVS_PASSFILE). Pour que la connexion aboutisse, ce fichier devra également exister dans $CVROOT/passwd

L'algorithme ci-dessous explicite l'utilisation que fait pserver de ces fichier pour décider d'accorder un droit d'accès en lecture seule ou en lecture-écriture à l'utilisateur user.

SI user n'existe pas dans le fichier passwd OU son mot de passe est incorrect ALORS ACCES REFUSE

SINON SI le fichier readers existe ET user y figure ALORS -> ACCES LECTURE SEULE

SINON SI le fichier writers existe ET user n'y figure pas ALORS -> ACCES LECTURE SEULE SINON -> ACCES LECTURE-ECRITURE FINSI

3. Kerberos

Le serveur CVS est en attente sur le port TCP 1999 ajoutez dans /etc/services:

cvskserver 1999/tcp

Dans inetd.conf

cvskserver stream tcp nowait cvs /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot kserver

Sur la machine cliente définir la variable CVSROOT

CVSROOT=:kserver:server:/usr/local/cvsroot

sur la machine cliente utilisez kinit pour obtenir un ticket kerberos vous permettant ensuite de vous connecter et d'utiliser les commandes cvs.

4. GSSAPI

Permet d'accéder à des systèmes sécurisés tel que kerberos 5. CVS et ses outils auront été compilés préalablement en incluant le support GSSAPI (option --with-gssapi). Ce mode est équivalent au mode serveur et utilise également le fichier $CVSROOT/passwd. Par défaut les communications ne sont ni authentifiées ni chiffrées et il faudra utiliser des options spéciales de CVS (voir détail des commandes man et info). Sur la machine cliente définir la variable CVSROOT

CVSROOT=:gserver:server:/usr/local/cvsroot

5. rsh et ssh

Dans ce mode le client accède au serveur en utilisant rsh. Sur la machine cliente définir la variable CVSROOT

CVSROOT=:ext:user@server:/usr/local/cvsroot

Vérifier que la commande rsh fonctionne indépendamment de cvs.

rsh -l user server uname -a

Il faudrait configurer rsh pour ne pas demander à chaque fois le mot de passe (.rhosts ou encore host.equiv), mais cette méthode n'est pas du tout sécurisée, nous utiliserons ssh en remplacement de rsh. Définissez la variable d'environnement CVS_RSH

CVS_RSH=ssh

Vous devrez mettre votre clef publique dans ~/.ssh/authorized_keys sur le serveur pour ne plus entrer le mot de passe à chaque fois. Nous retiendrons ce mode ou shell sécurisé utilisant kerberos pour toutes communications distantes afin d'éviter d'exposer votre système à des attaques, en chiffrant les connexions et les transferts de données.

# depuis le poste client

$ ssh-keygen -t dsa # PubkeyAuthentication : clé DSA pour SSH2

$ cat .ssh/id_dsa.pub | ssh user1@remote

"cat - >>.ssh/authorized_keys[2]"

Modules

Chaque projet que vous ajoutez dans CVS correspond à un module. Pour ajouter un module :

mkdir /usr/local/cvsroot/nom_projet && mkdir /var/lock/cvs/nom_projet

chowm cvs:groupe_du_projet /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet

chmod g+rwxs /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet

5 Logiciel de gestion de version décentralisée « Git » :

Git est un projet initié en 2005 par Linus Torvalds lorsque la licence du précédent gestionnaire de versions utilisé pour le noyau Linux (BitKeeper) ne lui permettait plus de l’utiliser gratuitement. Il est rapidement devenu une référence sur le sujet et on le comprend vite lorsque l’on s’intéresse à l’écosystème qui gravite autour du développement du noyau Linux : une communauté répartie tout autour du globe et un nombre important de branches qui vivent en parallèle

5.1. Principe de Fonctionnement de Git:

Commençons par l’initialisation d’un projet géré à l’aide de Git par un développeur seul (Alice). Celle-ci travaille sur sa copie de travail locale, comme avec Subversion, mais avec un dépôt local cette fois-ci :

Figure : Le principe de fonctionnement de Git

Alice initialise son dépôt personnel sur son poste et enregistre ses modifications sur celui-ci. Pas besoin d’accès à un serveur (mode déconnecté).

git init                # initialisation du dépôt

git add ...           # ajout de fichiers

git commit -a    # commit des modifications/ajouts dans le dépôt

5.2. Démarrer un dépôt Git

Vous pouvez principalement démarrer un dépôt Git de deux manières. La première consiste à prendre un projet ou un répertoire existant et à l'importer dans Git. La seconde consiste à cloner un dépôt Git existant sur un autre serveur.

5.2.1. Initialisation d'un dépôt Git dans un répertoire existant

Si vous commencer à suivre un projet existant dans Git, vous n'avez qu'à vous positionner dans le répertoire du projet et saisir

$ git init

Cela crée un nouveau sous-répertoire nommé .git qui contient tous les fichiers nécessaire au dépôt — un squelette de dépôt Git. Pour l'instant, rien n'est encore suivi en version. (Cf. chapitre 9 pour plus d'information sur les fichiers contenus dans le répertoire .git que vous venez de créer.)

Si vous souhaitez mettre sous gestion de version des fichiers existants (contrairement à un répertoire vide), vous devriez probablement commencer par indexer ces fichiers et faire un commit initial. Vous pouvez réaliser ceci avec un poignée de commandes Git qui spécifient les fichiers que vous souhaitez suivre, suivi d'un commit :

$ git add *.c

$ git add README

$ git commit –m 'version initiale du projet'

Nous allons passer en revue ce que ces commandes font dans une petite minute. Pour l'instant, vous avez un dépôt git avec des fichiers sous gestion de version et un commit initial.

5.2.2. Cloner un dépôt existant

Si vous souhaitez obtenir une copie d« un dépôt Git existant — par exemple, un projet auquel vous aimeriez contribuer — la commande dont vous avez besoin s'appelle git clone. Si vous êtes familier avec d'autres systèmes de gestion de version tels que Subversion, vous noterez que la commande est 'clone » et non « checkout ». C'est une distinction importante — Git reçoit une copie de quasiment toutes les données dont le serveur dispose. Toutes les versions de tous les fichiers pour l'historique du projet sont téléchargées quand vous lancez git clone. En fait, si le disque du serveur se corrompt, vous pouvez utiliser n'importe quel clone pour remettre le serveur dans l'état où il était au moment du clonage (vous pourriez perdre quelques paramètres du serveur, mais toutes les données sous gestion de version serait récupérées — Cf. chapitre 4 pour de plus amples détails).

Vous clonez un dépôt avec git clone [url]. Par exemple, si vous voulez cloner la bibliothèque Git Ruby appelée Grit, vous pouvez le faire de manière suivante :

$ git clone git://github.com/schacon/grit.git

Ceci crée un répertoire nommé « grit », initialise un répertoire .git à l'intérieur, récupère toutes les données de ce dépôt, et extrait une copie de travail de la dernière version. Si vous examinez le nouveau répertoire grit, vous y verrez les fichiers du projet, prêt à être modifiés ou utilisés. Si vous souhaitez cloner le dépôt dans un répertoire nommé différemment, vous pouvez spécifier le nom dans une option supplémentaire de la ligne de commande :

$ git clone git://github.com/schacon/grit.git mygrit

Cette commande réalise la même chose que la précédente, mais le répertoire cible s'appelle mygrit.

Git dispose de différents protocoles de transfert que vous pouvez utiliser. L'exemple précédent utilise le protocole git://, mais vous pouvez aussi voir http(s):// ou utilisateur@serveur:/chemin.git, qui utilise le protocole de transfert SSH. Le chapitre 4 introduit toutes les options disponibles pour mettre en place un serveur Git, ainsi que leurs avantages et inconvénients.

5.3. Enregistrer des modifications dans le dépôt

Vous avez à présent un dépôt Git valide et une extraction ou copie de travail du projet. Vous devez faire quelques modifications et valider des instantanés de ces modifications dans votre dépôt chaque fois que votre projet atteint un état que vous souhaitez enregistrer.

Souvenez-vous que chaque fichier de votre copie de travail peut avoir deux états : sous suivi de version ou non suivi. Les fichiers suivis sont les fichiers qui appartenait déjà au dernier instantané ; ils peuvent être inchangés, modifiés ou indexés. Tous les autres fichiers sont non suivis — tout fichier de votre copie de travail qui n'appartenait pas à votre dernier instantané et n'a pas été indexé. Quand vous clonez un dépôt pour la première fois, tous les fichiers seront sous suivi de version et inchangés car vous venez tout juste de les enregistrer sans les avoir encore édités.

Au fur et à mesure que vous éditez des fichiers, Git les considère comme modifiés, car vous les avez modifiés depuis le dernier instantané. Vous indexez ces fichiers modifiés et vous enregistrez toutes les modifications indexées, puis ce cycle se répète. Ce cycle de vie est illustré par la figure

Figure 2.1. Figure 2–1. Le cycle de vie des états des fichiers.

5.3.1. Vérifier l'état des fichiers

L'outil principal pour déterminer quels fichiers sont dans quel état est la commande git status. Si vous lancez cette commande juste après un clonage, vous devriez voir ce qui suit :

$ git status

# On branch master

nothing to commit (working directory clean)

Ce message signifie que votre copie de travail est propre, en d'autres mots, aucun fichier suivi n'a été modifié. Git ne voit pas non plus de fichiers non-suivis, sinon ils seraient listés ici. Enfin, la commande vous indique sur quelle branche vous êtes. Pour l'instant, c'est toujours master, qui correspond à la valeur par défaut ; nous ne nous en soucierons pas maintenant. Dans le chapitre suivant, nous parlerons plus en détail des branches et des références.

Supposons que vous ajoutiez un nouveau fichier à votre projet, un simple fichier LISEZMOI. Si ce fichier n'existait pas auparavant, et que vous lancez la commande git status, vous verrez votre fichier non suivi comme ceci :

# On branch master

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#       LISEZMOI

nothing added to commit but untracked files present (use "git add" to track)

5.3.2 Placer de nouveaux fichiers sous suivi de version

Pour commencer à suivre un nouveau fichier, vous utilisez la commande git add. Pour commencer à suivre le fichier LISEZMOI, vous pouvez entrer ceci :

$ git add LISEZMOI

Si vous lancez à nouveau le commande status, vous pouvez constater que votre fichier LISEZMOI est maintenant suivi et indexé :

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#       new file:   LISEZMOI

Vous pouvez affirmer qu'il est indexé car il apparaît dans la section « Changes to be committed » (Modifications à enregistrer).Si vous enregistrez à ce moment, la version du fichier à l'instant où vous lancez git add est celle qui appartiendra à l'instantané. Vous pouvez vous souvenir que lorsque vous avez précédemment lancé git init, vous avez ensuite lancé git add (fichiers) — c'était bien sur pour commencer à placer sous suivi de version les fichiers de votre répertoire de travail. La commande git add accepte en paramètre un chemin qui correspond à un fichier ou un répertoire ; dans le cas d'un répertoire, la commande ajoute récursivement tous les fichiers de ce répertoire.

5.3.3. Indexer des fichiers modifiés

Maintenant, modifions un fichiers qui est déjà sous suivi de version. Si vous modifiez le fichier sous suivi de version appelé benchmarks.rb et que vous lancez à nouveau votre commande status, vous verrez ceci :

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#       new file:   LISEZMOI

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#       modified:   benchmarks.rb

Le fichier benchmarks.rb apparaît sous la section nommée « Changed but not updated » ce qui signifie que le fichier sous suivi de version a été modifié dans la copie de travail mais n'est pas encore indexé. Pour l'indexer, il faut lancer la commande git add (qui est une commande multi-usage — elle peut être utilisée pour placer un fichier sous suivi de version, pour indexer un fichier ou pour d'autres actions telles que marquer comme résolu des conflits de fusion de fichiers). Lançons maintenant git add pour indexer le fichier benchmarks.rb, et relançons la commande git status :

$ git add benchmarks.rb

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#       new file:   LISEZMOI

#       modified:   benchmarks.rb

A présent, les deux fichiers sont indexés et feront partie de la prochaine validation. Mais supposons que vous souhaitiez apporter encore une petite modification au fichier benchmarks.rb avant de réellement valider la nouvelle version. Vous l'ouvrez à nouveau, réalisez la petite modification et vous voilà prêt à valider. Néanmoins, vous lancez git status une dernière fois :

$ vim benchmarks.rb

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#       new file:   LISEZMOI

#       modified:   benchmarks.rb

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#       modified:   benchmarks.rb

5.3.4. Ignorer des fichiers

Il apparaît souvent qu'un type de fichiers présent dans la copie de travail ne doit pas être ajouté automatiquement ou même apparaître comme fichier potentiel pour le suivi de version. Ce sont par exemple des fichiers générés automatiquement tels que les fichiers de journaux ou de sauvegardes produits par l'outil que vous utilisez. Dans un tel cas, on peut énumérer les patrons de noms de fichiers à ignorer dans un fichier .gitignore. Voici ci-dessous un exemple de fichier .gitignore :

$ cat .gitignore

*.[oa]

*~

La première ligne ordonne à Git d'ignorer tout fichier se terminant en .o ou .a — des fichiers objet ou archive qui sont généralement produits par la compilation d'un programme. La seconde ligne indique à Git d'ignorer tous les fichiers se terminant par un tilde (~), ce qui est le cas des noms des fichiers temporaires pour de nombreux éditeurs de texte tels qu'Emacs. On peut aussi inclure un répertoire log, tmp ou pid, ou le répertoire de documentation générée automatiquement, ou tout autre fichier. Renseigner un fichier .gitignore avant de commencer à travailler est généralement une bonne idée qui évitera de valider par inadvertance des fichiers qui ne doivent pas apparaître dans le dépôt Git.

Les règles de construction des patrons à placer dans le fichier .gitignore sont les suivantes :

· Les lignes vides ou commençant par # sont ignorée

· Les patrons standards de fichiers sont utilisables

· Si le patron se termine par un slash (/), le patron dénote un répertoire

· Un patron commençant par un point d'exclamation (!) est inversé.

Les patrons standards de fichiers sont des expressions régulières simplifiées utilisées par les shells. Un astérisque (*) correspond à un ou plusieurs caractères ; [abc] correspond à un des trois caractères listés dans les crochets, donc a ou b ou c ; un point d'interrogation (?) correspond à un unique caractère ; des crochets entourant des caractères séparés par un signe moins ([0-9]) correspond à un caractère dans l'intervalle des deux caractères indiqués, donc ici de 0 à 9.

Voici un autre exemple de fichier .gitignore :

$ git status

# On branch master

# Changes to be committed:

#   (use "git reset HEAD <file>..." to unstage)

#       new file:   LISEZMOI

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#       modified:   benchmarks.rb

Pour visualiser ce qui a été modifié mais pas encore indexé, tapez git diff sans autre argument :

$ git diff

diff --git a/benchmarks.rb b/benchmarks.rb

index 3cb747f..da65585 100644

--- a/benchmarks.rb

+++ b/benchmarks.rb

@@ -36,6 +36,10 @@ def main

           @commit.parents[0].parents[0].parents[0]

end

5.3.5. Inspecter les modifications indexées et non indexées

Si le résultat de la commande git status est encore trop vague — lorsqu'on désire savoir non seulement quels fichiers ont changé mais aussi ce qui a changé dans ces fichiers — on peut utiliser la commande git diff. Cette commande sera traitée en détail plus loin ; mais elle sera vraisemblablement utilisée le plus souvent pour répondre aux questions suivantes : qu'est-ce qui a été modifié mais pas encore indexé ? Quelle modifications a été indexée et est prête pour la validation ? Là où git status répond de manière générale à ces questions, git diff montre les lignes exactes qui ont été ajoutées, modifiées ou effacées — le patch en somme.

Supposons que vous éditez et indexez le fichier LISEZMOI et que vous éditez le fichier benchmarks.rb sans l'indexer. Si vous lancez la commande status, vous verrez ceci :

Conclusion Générale

Les VCS ont accompagné les auteurs et développeurs depuis de nombreuses années. Les plus anciens étaient très contraignants par leur modèle de verrouillage préalable. CVS a libéré les auteurs et les développeurs et a montré depuis des années que le modèle où on édite d’abord et on fusionne (éventuellement) après était viable, alors que beaucoup d’experts prédisaient que cela mènerait au désordre.

Aujourd’hui, les VCS décentralisés peuvent être inquiéter car il s’agit d’un modèle nouveau et qui semble moins contrôlé. Mais le développement du noyau Linux, où ce modèle est utilisé depuis plusieurs années, montre que le développement décentralisé est possible. Si les outils sont encore primitifs (par exemple, les mécanismes de publication sur le réseau sont sommaires), et trop nombreux (une sélection darwinienne va être nécessaire) le paradigme des VCS décentralisés est déjà bien installé et représente certainement l’avenir.

Pendant très longtemps, l’unique logiciel libre et sérieux de gestion de versions était CVS. Il reste aujourd’hui la référence. Mais maintenant que ce vénérable logiciel atteint sérieusement ses limites et que la créativité bouillonne dans ce domaine, après dix ans de monopole absolu de CVS, il est temps de présenter la concurrence.

Pour succéder à CVS, il existe deux sortes de logiciels, centralisés ou décentralisés. La première catégorie est essentiellement représentée par Subversion, la seconde comprend de nombreux logiciels, dont la plupart ne sont pas encore très stables, mais elle représente probablement l’avenir de la gestion de versions.

Dans ces systèmes de gestion de versions décentralisés (comme darcs, mercurial ou cogito), il n’y a plus de dépôt de référence. Plusieurs dépôts coexistent et on peut lire et écrire dans celui de son choix.

Ils permettent ainsi un développement lui-même très décentralisé et collent donc au style de développement de la majorité des logiciels libres.

Correction sommaire par Messoud Samar

2011-04-06T00:12:06+01:00

Sommaire

Introduction Générale. 1

1. Définitions: 1

1.1.      Les versions : 1

1.2.      La gestion de versions : 1

1.2.1.       Le système de gestion de versions : 1

1.2.2.       Utilité des systèmes de gestion de version : 2

2.       Types de gestion de version : 2

2.1        Gestion de version centralisée : 2

2.2        Gestion de version décentralisée : 3

2.2.1. Avantages de la Gestion de version décentralisée : 4

2.2.2. Désavantages : 4

3.       Logiciels de gestion de version : 5

3.1.      Local : 6

3.2.      Modèle client-serveur. 6

3.2.1.       Libre : 6

3.2.2.       Propriétaire : 6

3.3. Distribué : 7

3.3.1        Libre : 7

3.3.2        Propriétaire : 7

4        Logiciel de gestion de version centralisée « CVS » : 7

4.1. Définition : 7

4.2. CVS et le travail en groupe. 7

4.3        Succès et Limites. 8

4.4        Les commandes principales de CVS : 9

4.5        Utilisation du référentiel 14

4.6        Horloge système et synchronisation. 15

5        Logiciel de gestion de version décentralisée « Git » : 21

5.1.      Principe de Fonctionnement de Git: 21

5.2. Démarrer un dépôt Git 22

5.2.1. Initialisation d'un dépôt Git dans un répertoire existant 22

5.2.2. Cloner un dépôt existant 22

5.3. Enregistrer des modifications dans le dépôt 23

5.3.1. Vérifier l'état des fichiers. 24

5.3.2 Placer de nouveaux fichiers sous suivi de version. 25

5.3.3. Indexer des fichiers modifiés. 25

5.3.4. Ignorer des fichiers. 26

5.3.5. Inspecter les modifications indexées et non indexées. 27
Conclusion Générale 28

But d'usage de gestion de version par:larbi khaoula

2011-03-30T19:22:34+01:00

Un logiciel de gestion de versions est un logiciel de gestion de configuration permettant de stocker des informations pour une ou plusieurs ressources informatiques permettant de récupérer toutes les versions intermédiaires des ressources, ainsi que les différences entre les versions.
Un logiciel de gestion de versions agit sur une arborescence de fichiers afin de conserver toutes les versions des fichiers, ainsi que les différences entre les fichiers. Ce système permet par exemple de mutualiser un développement. Un groupe de développeurs autour d'un même développement se servira de l'outil pour stocker toute évolution du code source.

Utilité des systèmes de gestion de version :

*Accès concurrentiel par plusieurs développeurs

*Suivi de l’historique

*Visualisation des déférences

*Retour `a des anciennes versions

Logiciels de gestion de versions par: larbi khaoula

2011-03-30T19:06:49+01:00

CVS
Subversion : http://subversion.tigris.org
Visual SourceSafe (Société Microsoft)
Perforce
ClearCase (Société Rational Software/IBM)
PVCS(Dimensions): http://www.serena.com/
SCCS
RCS
GNU Arch : http://www.gnu.org/software/gnu-arch/
Bazaar : http://bazaar.canonical.com (compatible avec GNU Arch) et son lointain descendant Bazaar-ng : http://www.bazaar-ng.org
Synergy (Société Telelogic)
Bitkeeper
SCM Surround (Société Seapine)
DaRCS : http://www.darcs.net/
git, utilisé entre autres pour le noyau GNU/linux
Mercurial : http://www.selenic.com/mercurial
So6, logiciel de gestion de configuration (La gestion de configuration consiste à gérer la description technique d'un système[1] (et de ses divers composants), ainsi qu'à gérer l'ensemble des modifications apportées au cours de l'évolution du système. La gestion de configuration est utilisée pour la gestion de systèmes complexes :) de LibreSource
MECASP, gestion de versions et fusion (En physique et en métallurgie, la fusion est le passage d'un corps de l'état solide vers l'état liquide. Pour un corps pur, c’est-à-dire pour une substance constituée de molécules toutes identiques, la fusion s'effectue à température constante. La température de fusion ou de solidification d'un...) de variantes : http://mecasp.free.fr
SVK, basé sur le système de fichier de Subversion : http://svk.elixus.org/
MKS : http://www.mks.com/
Vault (Société SourceGear)
Monotone
ALDON Lifecycle Manager (Société ALDON): http://www.aldon.fr
JediVCS http://jedivcs.sourceforge.net/

cvs

2011-03-30T18:36:27+01:00

Réalisé par Jarboui Lobna

Exemple de gestion de version :

CVS : Concurrent Versions System est un système de gestion de versions, successeur de SCCS(Source Code Control System) originalement écrit par Dick Grune en 1986, puis complété par Brian Berliner (avec le programme cvs lui-même) en 1989, et par la suite amélioré par de très nombreux contributeurs. Puisqu'il aide les sources à converger vers la même destination, on dira que CVS fait la gestion concurrente de versions ou de la gestion de versions concurrentes. Il peut aussi bien fonctionner en mode ligne de commande qu'à travers une interface graphique. Il se compose de modules clients et d'un ou plusieurs modules serveur pour les zones d'échanges.

En effet, CVS est un système de contrôle de versions de fichiers. Le serveur CVS permet de conserver l'historique de toutes les modifications successives et de leur description, des fichiers placés sous son contrôle (généralement du code source) et de leur description. Le serveur CVS dispose d'un mécanisme intelligent de fusion des modifications apportées sur des fichiers texte, ce qui permet de gérer l'édition de fichiers par plusieurs auteurs en parallèle et de gérer les conflits possibles, de déclencher des actions (mail, scripts, ...) à différents moments du cycle de vie des fichiers ou du projet. Nous pouvons obtenir des images des projets aux différents moments de leur vie (version majeure, mise à jour, correctif, ...). Par exemple nous pouvons récupérer très simple la version 1.x d'un projet y apporter des modifications, et dans le même temps revenir à la version principale et continuer son travail.

Horloge système et synchronisation

Le dépôt (repository)

Initialisation du dépôt

Dans le cas on installe CVS pour la première fois, ou qu’on n’a pas de dépôt. Une fois la variable d'environnement CVSROOT définie, sur le serveur, on lance la commande :

mkdir /usr/local/cvsroot

cvs init

ou pour plus de contrôle sur la création du dépôt :

                     cvs -d /usr/local/cvsroot init

 chown -R cvs:cvs /usr/local/cvsroot

     chmod g+rwxs /usr/local/cvsroot/CVSROOT

Pour les accès en mode connecté, vous devrez ensuite créer le fichier $CVSROOT/CVSROOT/passwd ayant la structure suivante:

login_CVS:[mot_de_passe_crypt][:login_systeme]

chmod 400 $CVSROOT/CVSROOT/passwd

c'est un des rares cas où vous irez modifier un fichier dans $CVSROOT/CVSROOT. L'accès se fait par l'utilisation des commandes CVS.

Configuration du serveur CVS

Accédez au serveur avec un utilisateur faisant partie du groupe cvs.

mkdir ~/Projets/

cd ~/Projets/

cvs -d /usr/local/cvsroot checkout CVSROOT

si la variable CVSROOT est définie l'option -d /usr/local/cvsroot est facultative

-rw-rw-r--    1 jmj      jmj           495 mai 17 01:49 checkoutlist

-rw-rw-r--    1 jmj      jmj           760 mai 17 01:49 commitinfo

-rw-rw-r--    1 jmj      jmj           986 mai 17 02:35 config

drwxr-xr-x    2 jmj      jmj          4096 mai 23 19:01 CVS/

-rw-rw-r--    1 jmj      jmj           602 mai 17 01:49 cvswrappers

-rw-rw-r--    1 jmj      jmj          1025 mai 17 01:49 editinfo

-rw-rw-r--    1 jmj      jmj          1141 mai 17 01:49 loginfo

-rw-rw-r--    1 jmj      jmj          1151 mai 17 01:49 modules

-rw-rw-r--    1 jmj      jmj           564 mai 17 01:49 notify

-rw-rw-r--    1 jmj      jmj           649 mai 17 01:49 rcsinfo

-rw-rw-r--    1 jmj      jmj           879 mai 17 01:49 taginfo

-rw-rw-r--    1 jmj      jmj          1026 mai 17 01:49 verifymsg

Modifiez le fichier config :

cd CVSROOT

vi config

# Exemple de fichier config

SystemAuth=no

LockDir=/var/lock/cvs

TopLevelAdmin=no

LogHistory=TOEFWUPCGMAR

RereadLogAfterVerify=always

Validez les modifications

 cvs commit -m "Configuration initiale de CVS" config

Accès au dépôt

L'accès à cette base CVS peut s'effectuer de 5 manières différentes:

Direct

CVSROOT=:local:/usr/local/cvsroot ou CVSROOT=/usr/local/cvsroot

Serveur

Le serveur CVS est en attente des requêtes clientes, sur le port TCP 2401. A ajouter dans /etc/services:

cvspserver      2401/tcp                    # CVS client/server operations

dans /etc/inetd.conf si vous utilisez inetd

cvspserver stream tcp nowait cvs /usr/bin/cvs cvs –allow root=/usr/local /cvsroot pserver

pour qu'inetd prenne en compte les changements dans son fichier de configuration

killall -HUP inetd

si vous utilisez xinetd

# CVS configuration for xinetd don't forget to specify your CVSROOT in

#  /etc/cvs/cvs.conf.

service cvspserver

  disable = no

        socket_type         = stream

        protocol            = tcp

        wait                = no

        user                = root

        passenv             = PATH

        server              = /usr/sbin/cvspserver

        server_args         = -f --allow-root=/usr/local/cvsroot pserver

pour que xinetd prenne en compte les changements :

killall -HUP xinetd

Sur la machine cliente définir la variable CVSROOT

CVSROOT=:pserver:user@server:/usr/local/cvsroot

L'authentification est réalisée grâce à la commande :

cvs login

qui enregistrera le mot de passe sous forme chiffrée dans le fichier .cvspass si la connexion est acceptée (pour changer le nom du fichier.cvspass, définissez le dans $CVS_PASSFILE). Pour que la connexion aboutisse, ce fichier devra également exister dans $CVROOT/passwd

L'algorithme ci-dessous explicite l'utilisation que fait pserver de ces fichier pour décider d'accorder un droit d'accès en lecture seule ou en lecture-écriture à l'utilisateur user.

SI user n'existe pas dans le fichier passwd OU son mot de passe est incorrect ALORS ACCES REFUSE

SINON SI le fichier readers existe ET user y figure ALORS -> ACCES LECTURE SEULE

SINON SI le fichier writers existe ET user n'y figure pas ALORS -> ACCES LECTURE SEULE SINON -> ACCES LECTURE-ECRITURE FINSI

Kerberos

Le serveur CVS est en attente sur le port TCP 1999 ajoutez dans /etc/services:

cvskserver  1999/tcp

dans inetd.conf

cvskserver stream tcp nowait cvs /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot kserver

Sur la machine cliente définir la variable CVSROOT

CVSROOT=:kserver:server:/usr/local/cvsroot

sur la machine cliente utilisez kinit pour obtenir un ticket kerberos vous permettant ensuite de vous connecter et d'utiliser les commandes cvs.

GSSAPI

CVSROOT=:gserver:server:/usr/local/cvsroot

rsh et ssh

Dans ce mode le client accède au serveur en utilisant rsh. Sur la machine cliente définir la variable CVSROOT

CVSROOT=:ext:user@server:/usr/local/cvsroot

Vérifier que la commande rsh fonctionne indépendamment de cvs.

rsh -l user server uname -a

CVS_RSH=ssh

        # depuis le poste client

        $ ssh-keygen -t dsa   # PubkeyAuthentication : clé DSA pour SSH2

        $ cat .ssh/id_dsa.pub | ssh user1@remote

                  "cat - >>.ssh/authorized_keys[2]"

Modules

Chaque projet que vous ajoutez dans CVS correspond à un module. Pour ajouter un module

mkdir /usr/local/cvsroot/nom_projet && mkdir /var/lock/cvs/nom_projet

chowm cvs:groupe_du_projet /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet

chmod g+rwxs /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet

Les commandes principales de CVS

cvs login (pour se connecter en mode client server)
cvs logout (pour se déconnecter en mode client server)
cvs import -m "Liste nouveaux composants" nom_projet/HOWTO LFO V1 (ajoute les fichiers du répertoire courant avec le vendeur-tag LFO et le release-tag V1, sans avoir de copie de travail et évite de recourir aux sous-commandes add et commit pour tous les fichiers et répertoires ajoutés)
cvs checkout nom_projet (récupère en local le module nom_projet)
cvs update (met à jour les fichiers de la copie de travail en local)
cvs status -v nom_fichier (visualise l'état et les noms de versions symboliques du fichier)
cvs -n update (idem que cvs status mais les informations sont plus condensées)
cvs add -m (ajout de la procédure d'installation" INSTALL, ajoute le fichier INSTALL)
cvs remove -f nom_fichier (supprime physiquement et dans la base CVS nom_fichier), pour être validée cette commande devra être suivie d'un cvs commit
cvs commit -m "première version" index.html (archive la version dans CVS)
cvs export -k v -d version_prod -r STABLE-V1_1 nom_projet (extrait une copie du module nom_projet dans le répertoire projet_v1_1 sans les répertoires de gestion utilisés par CVS)
cd nom_projet/srv_server & cvs tag SRV-V1_0 (défini le nom symbolique SRV-V1_0 pour tous les fichiers de nom_projet/srv_server)
cvs co -r SRV-V1_0 nom_projet/srv_server (récupère les fichiers ayant le tag SRV-V1_0 de nom_projet/srv_server)
cvs rtag SRV-V2_0 nom_projet (défini le nom symbolique SRV-V2_0 à la dernière version présente dans la base des fichiers du module nom_projet)
cvs diff --ifdef=V1_2 -r1.1 -r1.3 index.html (affiche les différences entre les versions 1.1 et 1.3 en séparant les modifications par le symbole préprocesseur V1_2)
cvs rdiff -s -r STABLE-V1_0 nom_projet (résume les différences entre la version S Exemple de gestion de version :
CVS : Concurrent Versions System est un système de gestion de versions, successeur de SCCS(Source Code Control System) originalement écrit par Dick Grune en 1986, puis complété par Brian Berliner (avec le programme cvs lui-même) en 1989, et par la suite amélioré par de très nombreux contributeurs. Puisqu'il aide les sources à converger vers la même destination, on dira que CVS fait la gestion concurrente de versions ou de la gestion de versions concurrentes. Il peut aussi bien fonctionner en mode ligne de commande qu'à travers une interface graphique. Il se compose de modules clients et d'un ou plusieurs modules serveur pour les zones d'échanges.

En effet, CVS est un système de contrôle de versions de fichiers. Le serveur CVS permet de conserver l'historique de toutes les modifications successives et de leur description, des fichiers placés sous son contrôle (généralement du code source) et de leur description. Le serveur CVS dispose d'un mécanisme intelligent de fusion des modifications apportées sur des fichiers texte, ce qui permet de gérer l'édition de fichiers par plusieurs auteurs en parallèle et de gérer les conflits possibles, de déclencher des actions (mail, scripts, ...) à différents moments du cycle de vie des fichiers ou du projet. Nous pouvons obtenir des images des projets aux différents moments de leur vie (version majeure, mise à jour, correctif, ...). Par exemple nous pouvons récupérer très simple la version 1.x d'un projet y apporter des modifications, et dans le même temps revenir à la version principale et continuer son travail.

Horloge système et synchronisation

L'horloge du serveur et toutes les machines clientes devront être synchronisées à l'aide de Network Time Protocol (un protocole qui permet de synchroniser via un réseau informatique, l'horloge locale d'ordinateurs sur une référence d'heure), en effet CVS se sert de l'heure et de la date pour effectuer ses opérations et cela est capital pour l'intégrité de la base CVS. En effet le serveur CVS effectuant des comparaisons entre les différentes versions du fichier, des écarts de dates entre les différents postes, mettront en péril l'intégrité de la base CVS.

Le dépôt (repository)

Le dépôt est la base centralisée de CVS à savoir les fichiers d'administration se trouvant dans le sous dossier CVSROOT ainsi que les dossiers des différents projets (livres, développements, sites web, ...). Ce répertoire peut se trouver n'importe où sur le système de fichiers (ex: /usr/local/cvsroot) et le chemin pour l'atteindre doit être défini dans la variable d'environnement $CVSROOT. Afin que chaque utilisateur d'un groupe de travail puisse travailler sur un projet, le dossier ($CVSROOT/nom_projet) devra avoir les droits en lecture et écriture sur le groupe ainsi que le bit s positionné (garanti que chaque fichier/dossier cré appartient au groupe), il en sera de même pour /var/lock/cvs/nom_projet.

Initialisation du dépôt

Dans le cas on installe CVS pour la première fois, ou qu’on n’a pas de dépôt. Une fois la variable d'environnement CVSROOT définie, sur le serveur, on lance la commande :

mkdir /usr/local/cvsroot

cvs init

ou pour plus de contrôle sur la création du dépôt :
```
                     cvs -d /usr/local/cvsroot init
```
```
 chown -R cvs:cvs /usr/local/cvsroot
```
```
     chmod g+rwxs /usr/local/cvsroot/CVSROOT
```
Pour les accès en mode connecté, vous devrez ensuite créer le fichier $CVSROOT/CVSROOT/passwd ayant la structure suivante:
```
login_CVS:[mot_de_passe_crypt][:login_systeme]
```
Ce fichier étant particulièrement sensible il est préférable de ne pas mettre les mêmes mots de passe que ceux pour se connecter au serveur et de donner les droit suivants au fichier passwd de cvs.
```
chmod 400 $CVSROOT/CVSROOT/passwd
```
c'est un des rares cas où vous irez modifier un fichier dans $CVSROOT/CVSROOT. L'accès se fait par l'utilisation des commandes CVS.

Configuration du serveur CVS

Accédez au serveur avec un utilisateur faisant partie du groupe cvs.
```
mkdir ~/Projets/
```
```
cd ~/Projets/
```
```
cvs -d /usr/local/cvsroot checkout CVSROOT
```
si la variable CVSROOT est définie l'option -d /usr/local/cvsroot est facultative
```
-rw-rw-r--    1 jmj      jmj           495 mai 17 01:49 checkoutlist
```
```
-rw-rw-r--    1 jmj      jmj           760 mai 17 01:49 commitinfo
```
```
-rw-rw-r--    1 jmj      jmj           986 mai 17 02:35 config
```
```
drwxr-xr-x    2 jmj      jmj          4096 mai 23 19:01 CVS/
```
```
-rw-rw-r--    1 jmj      jmj           602 mai 17 01:49 cvswrappers
```
```
-rw-rw-r--    1 jmj      jmj          1025 mai 17 01:49 editinfo
```
```
-rw-rw-r--    1 jmj      jmj          1141 mai 17 01:49 loginfo
```
```
-rw-rw-r--    1 jmj      jmj          1151 mai 17 01:49 modules
```
```
-rw-rw-r--    1 jmj      jmj           564 mai 17 01:49 notify
```
```
-rw-rw-r--    1 jmj      jmj           649 mai 17 01:49 rcsinfo
```
```
-rw-rw-r--    1 jmj      jmj           879 mai 17 01:49 taginfo
```
```
-rw-rw-r--    1 jmj      jmj          1026 mai 17 01:49 verifymsg
```
Modifiez le fichier config :
```
 
```
```
 
```
```
cd CVSROOT
```
```
vi config
```
```
 
```
```
# Exemple de fichier config
```
```
SystemAuth=no
```
```
LockDir=/var/lock/cvs
```
```
TopLevelAdmin=no
```
```
LogHistory=TOEFWUPCGMAR
```
```
RereadLogAfterVerify=always
```
Validez les modifications
```
 cvs commit -m "Configuration initiale de CVS" config
```
Accès au dépôt

L'accès à cette base CVS peut s'effectuer de 5 manières différentes:

Direct

Les fichiers dans ce cas doivent être accessible directement au travers du système de fichier ou d'un système de fichier réparti tel que NFS ou SMB. Dans ce cas nous utilisons CVS en mode non connecté.
```
CVSROOT=:local:/usr/local/cvsroot ou CVSROOT=/usr/local/cvsroot
```
Serveur

Le serveur CVS est en attente des requêtes clientes, sur le port TCP 2401. A ajouter dans /etc/services:
```
cvspserver      2401/tcp                    # CVS client/server operations
```
dans /etc/inetd.conf si vous utilisez inetd
```
cvspserver stream tcp nowait cvs /usr/bin/cvs cvs –allow root=/usr/local /cvsroot pserver
```
pour qu'inetd prenne en compte les changements dans son fichier de configuration
```
killall -HUP inetd
```
si vous utilisez xinetd
```
# CVS configuration for xinetd don't forget to specify your CVSROOT in
```
```
#  /etc/cvs/cvs.conf.
```
```
service cvspserver
```
```
{
```
```
  disable = no
```
```
        socket_type         = stream
```
```
        protocol            = tcp
```
```
        wait                = no
```
```
        user                = root
```
```
        passenv             = PATH
```
```
        server              = /usr/sbin/cvspserver
```
```
        server_args         = -f --allow-root=/usr/local/cvsroot pserver
```
```
}
```
```
          
```
pour que xinetd prenne en compte les changements :
```
killall -HUP xinetd
```
Sur la machine cliente définir la variable CVSROOT
```
CVSROOT=:pserver:user@server:/usr/local/cvsroot
```
L'authentification est réalisée grâce à la commande :
```
cvs login
```
qui enregistrera le mot de passe sous forme chiffrée dans le fichier .cvspass si la connexion est acceptée (pour changer le nom du fichier.cvspass, définissez le dans $CVS_PASSFILE). Pour que la connexion aboutisse, ce fichier devra également exister dans $CVROOT/passwd

L'algorithme ci-dessous explicite l'utilisation que fait pserver de ces fichier pour décider d'accorder un droit d'accès en lecture seule ou en lecture-écriture à l'utilisateur user.

SI user n'existe pas dans le fichier passwd OU son mot de passe est incorrect ALORS ACCES REFUSE

SINON SI le fichier readers existe ET user y figure ALORS -> ACCES LECTURE SEULE

SINON SI le fichier writers existe ET user n'y figure pas ALORS -> ACCES LECTURE SEULE SINON -> ACCES LECTURE-ECRITURE FINSI

Kerberos

Le serveur CVS est en attente sur le port TCP 1999 ajoutez dans /etc/services:
```
cvskserver  1999/tcp
```
dans inetd.conf
```
cvskserver stream tcp nowait cvs /usr/bin/cvs cvs --allow-root=/usr/local/cvsroot kserver
```
Sur la machine cliente définir la variable CVSROOT
```
CVSROOT=:kserver:server:/usr/local/cvsroot
```
sur la machine cliente utilisez kinit pour obtenir un ticket kerberos vous permettant ensuite de vous connecter et d'utiliser les commandes cvs.

GSSAPI

Permet d'accéder à des systèmes sécurisés tel que kerberos 5. CVS et ses outils auront été compilés préalablement en incluant le support GSSAPI (option --with-gssapi). Ce mode est équivalent au mode serveur et utilise également le fichier $CVSROOT/passwd. Par défaut les communications ne sont ni authentifiées ni chiffrées et il faudra utiliser des options spéciales de CVS (voir détail des commandes man et info). Sur la machine cliente définir la variable CVSROOT
```
CVSROOT=:gserver:server:/usr/local/cvsroot
```
rsh et ssh

Dans ce mode le client accède au serveur en utilisant rsh. Sur la machine cliente définir la variable CVSROOT
```
CVSROOT=:ext:user@server:/usr/local/cvsroot
```
Vérifier que la commande rsh fonctionne indépendamment de cvs.
```
rsh -l user server uname -a
```
Il faudrait configurer rsh pour ne pas demander à chaque fois le mot de passe (.rhosts ou encore host.equiv), mais cette méthode n'est pas du tout sécurisée, nous utiliserons ssh en remplacement de rsh. Définissez la variable d'environnement CVS_RSH
```
CVS_RSH=ssh
```
Vous devrez mettre votre clef publique dans ~/.ssh/authorized_keys sur le serveur pour ne plus entrer le mot de passe à chaque fois. Nous retiendrons ce mode ou shell sécurisé utilisant kerberos pour toutes communications distantes afin d'éviter d'exposer votre système à des attaques, en chiffrant les connexions et les transferts de données.
```
        # depuis le poste client
```
```
        $ ssh-keygen -t dsa   # PubkeyAuthentication : clé DSA pour SSH2
```
```
        $ cat .ssh/id_dsa.pub | ssh user1@remote 
```
```
                  "cat - >>.ssh/authorized_keys[2]"
```
Modules

Chaque projet que vous ajoutez dans CVS correspond à un module. Pour ajouter un module
```
mkdir /usr/local/cvsroot/nom_projet && mkdir /var/lock/cvs/nom_projet
```
```
chowm cvs:groupe_du_projet /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet
```
```
chmod g+rwxs /usr/local/cvsroot/nom_projet /var/lock/cvs/nom_projet
```
Les commandes principales de CVS
- cvs login (pour se connecter en mode client server)
- cvs logout (pour se déconnecter en mode client server)
- cvs import -m "Liste nouveaux composants" nom_projet/HOWTO LFO V1 (ajoute les fichiers du répertoire courant avec le vendeur-tag LFO et le release-tag V1, sans avoir de copie de travail et évite de recourir aux sous-commandes add et commit pour tous les fichiers et répertoires ajoutés)
- cvs checkout nom_projet (récupère en local le module nom_projet)
- cvs update (met à jour les fichiers de la copie de travail en local)
- cvs status -v nom_fichier (visualise l'état et les noms de versions symboliques du fichier)
- cvs -n update (idem que cvs status mais les informations sont plus condensées)
- cvs add -m (ajout de la procédure d'installation" INSTALL, ajoute le fichier INSTALL)
- cvs remove -f nom_fichier (supprime physiquement et dans la base CVS nom_fichier), pour être validée cette commande devra être suivie d'un cvs commit
- cvs commit -m "première version" index.html (archive la version dans CVS)
- cvs export -k v -d version_prod -r STABLE-V1_1 nom_projet (extrait une copie du module nom_projet dans le répertoire projet_v1_1 sans les répertoires de gestion utilisés par CVS)
- cd nom_projet/srv_server & cvs tag SRV-V1_0 (défini le nom symbolique SRV-V1_0 pour tous les fichiers de nom_projet/srv_server)
- cvs co -r SRV-V1_0 nom_projet/srv_server (récupère les fichiers ayant le tag SRV-V1_0 de nom_projet/srv_server)
- cvs rtag SRV-V2_0 nom_projet (défini le nom symbolique SRV-V2_0 à la dernière version présente dans la base des fichiers du module nom_projet)
- cvs diff --ifdef=V1_2 -r1.1 -r1.3 index.html (affiche les différences entre les versions 1.1 et 1.3 en séparant les modifications par le symbole préprocesseur V1_2)
- cvs rdiff -s -r STABLE-V1_0 nom_projet (résume les différences entre la version STABLE-V1_0 et la dernière version en base)
- cvs rdiff -u -r STABLE-V1_0 nom_projet (visualise les différences)
- cvs release -d nom_projet (vérifie que toutes vos modifications sont archivées et indique à CVS que vous n'utilisez plus votre copie de travail)
TABLE-V1_0 et la dernière version en base)
cvs rdiff -u -r STABLE-V1_0 nom_projet (visualise les différences)
cvs release -d nom_projet (vérifie que toutes vos modifications sont archivées et indique à CVS que vous n'utilisez plus votre copie de travail)

Le modèle de CVS est un modèle centralisé, où un serveur central regroupe toutes les sources, mais il existe aussi des logiciels décentralisés comme Bazaar, Darcs, Git, Mercurial, Fossil ou Monotone, tous ces derniers étant des logiciels libres.

les types d'outil de gestion de version

2011-03-30T15:43:29+01:00

Modèle centralisé

Rappelons tout d’abord le principe de fonctionnement de version (et de tous les systèmes de gestion de version non-distribués) afin de bien saisir les différences entre distribué et centralisé.
Subversion est donc composé d’un dépôt unique sur un serveur où se trouve l’ensemble des fichiers, de leurs versions ainsi que des branches qui permettent de gérer plusieurs versions du projet en parallèle.
Les développeurs (Alice et Bob par exemple) récupèrent une version du projet sur leur poste de travail (avec la commande checkout) pour pouvoir commencer à travailler dessus. Au quotidien, ils mettent à jour leur copie de travail local (update) depuis le serveur Subversion et renvoient leurs modifications (commit) vers ce même serveur. Ce mode de fonctionnement permet aux développeurs de travailler en parallèle sur le projet, de partager leurs modifications et de versionner les fichiers qu’ils modifient.

Shéma montre le principe de fonctionnemet de logiciel centralisé

Modèle Décentralisé

Lorsque l’on parle de gestion de version distribuée, cela signifie que le dépôt de fichier n’est plus unique sur un serveur mais que chaque développeur possède son propre dépôt. Chacun de ces dépôts contient l’ensemble des versions des fichiers. C’est de ce principe que découle toutes les autres fonctionnalités d’outils comme Git, Mercurial ou encore Bazaar. Pour illustrer cet article, les exemples s’appuieront sur Git. Même s’ils diffèrent dans le détail, les principes de dépôts multiples et d’échange entre ces dépôts restent globalement les mêmes pour chacun de ces outils.

Exemple : Git

Principe de Fonctionnement de Git:

Shéma montre le principe de fonctionnement de Git

Alice initialise son dépôt personnel sur son poste et enregistre ses modifications sur celui-ci. Pas besoin d’accès à un serveur (mode déconnecté).

1
2
3

git init                # initialisation du dépôt
git add ...           # ajout de fichiers
git commit -a    # commit des modifications/ajouts dans le dépôt