- Archives
-
Correction du rapport Publié le Samedi 9 Avril 2011 à 02:43:54
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
1.2.1. Le système de gestion de versions :
1.2.2. Utilité des systèmes de gestion de version :
2. Types de gestion de version :
2.1 Gestion de version centralisée :
2.2 Gestion de version décentralisée :
2.2.1. Avantages de la Gestion de version décentralisée :
3. Logiciels de gestion de version :
4 Logiciel de gestion de version centralisée « CVS » :
4.2. CVS et le travail en groupe
4.4 Les commandes principales de CVS :
4.5 Utilisation du référentiel
4.6 Horloge système et synchronisation
5 Logiciel de gestion de version décentralisée « Git » :
5.1. Principe de Fonctionnement de Git:
5.2.1. Initialisation d'un dépôt Git dans un répertoire existant
5.2.2. Cloner un dépôt existant
5.3. Enregistrer des modifications dans le dépôt
5.3.1. Vérifier l'état des fichiers
5.3.2 Placer de nouveaux fichiers sous suivi de version
5.3.3. Indexer des fichiers modifiés
5.3.5. Inspecter les modifications indexées et non indexées
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.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.
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
ü 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 :
Libre :
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
ü Dimensions CM (Serena Software)
ü ALDON Lifecycle Manager (ALDON): http://www.aldon.frClearCase (Rational Software/IBM)
ü IBM Rational Team Concert (Rational Software/IBM)
ü MKS Integrity: http://www.mks.com/
ü Perforce
ü SCM Surround (Société Seapine)
ü Vault (SourceGear)
ü Visual SourceSafe (Microsoft)
ü Microsoft Visual Studio Application Lifecycle Management
ü Team Foundation Server (Microsoft)
ü 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/
ü 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 » :
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.
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 monprojetUn 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.cRessusciter 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.cBien 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,vL'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.cLe 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 commitDans 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 monprojetDiff : 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.cVoir les différences entre plusieurs versions d’un fichier
$ cvs diff -r revision1 -r revision2 fichierRestaurer 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.cImport : 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:
- Se mettre dans le répertoire où sont les sources et répertoires.
- Taper : “cvs import d1 d2”. d1 et d2 sont des textes bidons, utiles seulement dans des cas particuliers.
- 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 updateVé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_1Ensuite, 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_7111Le 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_FIX1016Il 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_AMELIORATION756Il 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é).
1
2
3
git init # initialisation du dépôtgit add ... # ajout de fichiersgit commit -a # commit des modifications/ajouts dans le dépôt5.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é
.gitqui 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.gitque 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 lancezgit 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épertoiregrit, 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 voirhttp(s)://ouutilisateur@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 masternothing 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)## LISEZMOInothing 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 addest 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.rbet que vous lancez à nouveau votre commandestatus, 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 maintenantgit addpour indexer le fichier benchmarks.rb, et relançons la commandegit 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 statusune 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 diffsans autre argument :$ git diffdiff --git a/benchmarks.rb b/benchmarks.rbindex 3cb747f..da65585 100644--- a/benchmarks.rb+++ b/benchmarks.rb@@ -36,6 +36,10 @@ def main@commit.parents[0].parents[0].parents[0]end5.3.5. Inspecter les modifications indexées et non indexées
Si le résultat de la commande
git statusest 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 commandegit 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 statusrépond de manière générale à ces questions,git diffmontre 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 :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.
Ecrire un commentaire - Permalien -
définitions d'activité 4.4.1, par: larbi khaoula Publié le Samedi 9 Avril 2011 à 01:47:36Clé public :
Une clé est
une chaîne de caractères permettant d’authentifier et de chiffrer (ou déchiffrer) un message.Il désigne une clé de chiffrement d'un message qui réclame une seconde clé pour être décodé. Le protocole
Un protocole est une méthode standard qui permet la communication entre des processus (s'exécutant éventuellement sur différentes machines), c'est-à-dire un ensemble de règles et de procédures à respecter pour émettre et recevoir des données sur un réseau. Il en existe plusieurs selon ce que l'on attend de la communication. Certains protocoles seront par exemple spécialisés dans l'échange de fichiers, d'autres pourront servir à gérer simplement l'état de la transmission et des erreurs.
On classe généralement les protocoles en deux catégories selon le niveau de contrôle des données que l'on désire :
- Les protocoles orientés connexion: Il s'agit des protocoles opérant un contrôle de transmission des données pendant une communication établie entre deux machines. dans un tel schéma, la machine réceptrice envoie des accusés de réception lors de la communication, ainsi la machine émettrice est garante de la validité des données qu'elle envoie. C’est donc à ce protocole que nous allons nous intéresser puisque le TCP/IP en fait partie.
- Les protocoles non orientés connexion: Il s'agit d'un mode de communication dans lequel la machine émettrice envoie des données sans prévenir la machine réceptrice, et la machine réceptrice reçoit les données sans envoyer d'avis de réception à la première. Nous laisserons de côté ces protocoles car ils ne sont pas l’objet de notre blog.
Le système TCP/IP
TCP/IP ou «Transmission Control Protocol/Internet Protocol » («protocole de contrôle de transmissions» en Français) est un protocole de transport fiable, en mode connecté, c’est-à-dire qu’il permet l’établissement d'une session de communication entre deux parties qui veulent échanger des données.
TCP/IP représente donc d'une certaine façon l'ensemble des règles de communication sur internet et se base sur la notion d'adressage IP, c'est-à-dire le fait de fournir une adresse IP à chaque machine du réseau afin de pouvoir acheminer des paquets de données. D'ailleurs, si vous souhaitez connaître votre adresse IP, consultez ce site. -il est en effet toujours utile de savoir à quelle adresse nous sommes référencés.
Chiffrement
En cryptographie, le chiffrement (parfois appelé à tort cryptage) est le procédé grâce auquel on peut rendre la compréhension d'un document impossible à toute personne qui n'a pas la clé de (dé)chiffrement.
Bien que le chiffrement (En cryptographie, le chiffrement (parfois appelé à tort cryptage) est le procédé grâce auquel on peut rendre la compréhension d'un document impossible à toute personne qui n'a pas la clé de (dé)chiffrement.) puisse rendre secret le sens d'un document (Dans son acception courante un document est généralement défini comme le support physique d'une information.), d'autres techniques cryptographiques sont nécessaires pour communiquer de façon sûre. Pour vérifier l'intégrité ou l'authenticité d'un document, on utilise respectivement un Message Authentification Code (MAC) ou une signature numérique. On peut aussi prendre en considération l'analyse de trafic dont la communication peut faire l'objet, puisque les motifs provenant de la présence de communications peuvent faire l'objet d'une reconnaissance de motifs. Pour rendre secrète la présence de communications, on utilise la stéganographie. La sécurité d'un système de chiffrement doit reposer sur le secret de la clé de chiffrement et non sur celui de l'algorithme. Le principe de Kerckhoffs suppose en effet que l'ennemi (ou la personne qui veut connaître le message chiffré) connaît l'algorithme utilisé.
Deux principaux types de chiffrement
Un système de chiffrement est dit :
- symétrique quand il utilise la même clé pour chiffrer et déchiffrer.
- asymétrique quand il utilise des clés différentes : une paire composée d'une clé publique, servant au chiffrement, et d'une clé privée, servant à déchiffrer. Le point fondamental soutenant cette décomposition publique/privée est l'impossibilité calculatoire de déduire la clé privée de la clé publique.
Les méthodes les plus connues sont le DES, le Triple DES et l'AES pour la cryptographie (La cryptographie est une des disciplines de la cryptologie s'attachant à protéger des messages (assurant confidentialité, authenticité et intégrité) en s'aidant souvent de secrets ou clés.) symétrique, et le RSA pour la cryptographie asymétrique, aussi appelée cryptographie à clé publique.
L'utilisation d'un système symétrique ou asymétrique dépend des tâches à accomplir. La cryptographie asymétrique (La cryptographie asymétrique, ou cryptographie à clé publique est fondée sur l'existence de fonctions à sens unique — c'est-à-dire qu'il est simple d'appliquer cette fonction à un message, mais extrêmement difficile de retrouver ce message à partir du moment où on l'a transformé.) présente deux intérêts majeurs : Elle supprime le problème de transmission sécurisée de la clé, et elle permet la signature électronique. Elle ne remplace cependant pas les systèmes symétriques car ses temps de calcul sont nettement plus longs.
Différence entre chiffrement et codage
Les opérations de chiffrement et de codage font partie de la théorie de l'information. La différence essentielle réside dans la volonté de protéger les informations et d'empêcher des tierces personnes d'accéder aux données dans le cas du chiffrement. Le codage consiste à transformer de l'information (des données) vers un ensemble de mots. Chacun de ces mots est constitué de symboles. La compression est un codage : on transforme les données (Dans les technologies de l'information (TI), une donnée est une description élémentaire, souvent codée, d'une chose, d'une transaction d'affaire, d'un événement, etc.) vers un ensemble (En théorie des ensembles, un ensemble, désigne intuitivement une collection d’objets (que l'on appelle éléments de l'ensemble), « une multitude qui peut être comprise comme un tout », comme l'énonçait, le créateur de cette théorie, le mathématicien Georg Cantor : « Unter einer...) de mots adéquats destinés à réduire la taille mais il n'y a pas de volonté de dissimuler (bien que cela se fasse implicitement en rendant plus difficile d'accès le contenu).
Le "code" dans le sens cryptographique du terme travaille au niveau de la sémantique (les mots ou les phrases). Par exemple, un code pourra remplacer le mot "avion" par un numéro. Le chiffrement travaille sur des composantes plus élémentaires du message, les lettres ou les bits, sans s'intéresser à la signification du contenu. Un code nécessite une table de conversion, aussi appelée "dictionnaire" (codebook en anglais). Ceci étant, "code" et "chiffrement" sont souvent employés de manière synonyme malgré cette différence.
On peut aussi considérer que le chiffrement doit résister à un adversaire « intelligent » qui peut attaquer de plusieurs manières alors que le codage est destiné à une transmission sur un canal qui peut être potentiellement bruité. Ce bruit est un phénomène aléatoire qui n'a pas d'« intelligence » intrinsèque mais peut toutefois être décrit mathématiquement.
Correction sommaire par Messoud Samar Publié le Mercredi 6 Avril 2011 à 00:12:06Sommaire
1.2.1. Le système de gestion de versions :
1.2.2. Utilité des systèmes de gestion de version :
2. Types de gestion de version :
2.1 Gestion de version centralisée :
2.2 Gestion de version décentralisée :
2.2.1. Avantages de la Gestion de version décentralisée :
3. Logiciels de gestion de version :
4 Logiciel de gestion de version centralisée « CVS » :
4.2. CVS et le travail en groupe
4.4 Les commandes principales de CVS :
4.5 Utilisation du référentiel
4.6 Horloge système et synchronisation
5 Logiciel de gestion de version décentralisée « Git » :
5.1. Principe de Fonctionnement de Git:
5.2.1. Initialisation d'un dépôt Git dans un répertoire existant
5.2.2. Cloner un dépôt existant
5.3. Enregistrer des modifications dans le dépôt
5.3.1. Vérifier l'état des fichiers
5.3.2 Placer de nouveaux fichiers sous suivi de version
5.3.3. Indexer des fichiers modifiés
5.3.5. Inspecter les modifications indexées et non indexées
Conclusion GénéraleSommaire: Réalisé par Messoud Samar Publié le Mardi 5 Avril 2011 à 22:40:021.2.1. Le système de gestion de versions :
1.2.2. Utilité des systèmes de gestion de version :
2. Types de gestion de version :
2.1 Gestion de version centralisée :
2.2 Gestion de version décentralisée :
2.2.1. Avantages de la Gestion de version décentralisée :
3. Logiciels de gestion de version :
5. Logiciel de gestion de version centralisée « CVS » :
5.2. CVS et le travail en groupe
5.4. Les commandes principales de CVS :
5.5. Utilisation du référentiel
5.6. Horloge système et synchronisation
6. Logiciel de gestion de version décentralisée « Git » :
Sommaire du rapport Réalisé par :Messoud Samar Publié le Dimanche 3 Avril 2011 à 23:08:05Sommaire
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
3. Avantages et inconvénients : 4
4. Logiciels de gestion de version : 5
5. Logiciel de gestion de version centralisée « CVS » : 7
5.2. CVS et le travail en groupe. 8
5.4. Les commandes principales de CVS : 9
5.5. Utilisation du référentiel 14
5.6. Horloge système et synchronisation. 15
6. Logiciel de gestion de version décentralisée « Git » : 21
Principe de Fonctionnement de Git: 21
