Subversion
Un article de Wiki de la communauté Mandriva.
Sommaire |
[modifier] Principe
[modifier] Le problème
Vous travaillez à plusieurs sur du code source. Vous avez plusieurs fichiers sources. Jusqu'à maintenant, la façon la plus simple de partager vos modifications étaient d'envoyer les fichiers par courriels aux autres personnes.
Et bien sûr, parfois, la personne qui reçoit a modifié les mêmes fichiers que vous et doit faire la fusion en utilisant des copier-coller. Et ensuite, elle se rend compte que plus rien ne marche....
L'autre possibilité, c'est de compartimenter les efforts de chacun des collaborateurs, mais alors c'est plus du travail d'équipe :)
[modifier] Ce qu'apporte Subversion
- Centralisation des versions du projet (serveur SVN)
- Accès à toutes les versions des fichiers
- Fusion automatique (si 2 personnes modifient 2 parties différentes d'une même fichier, SVN fait la fusion)
- Gestion des conflits (si 2 personnes modifient la même chose, SVN signale le conflit et permet de le résoudre)
[modifier] Installation
Il suffit d'installer le paquet subversion.
[modifier] Obtenir le code
Pour participer à un projet, la première chose à faire est de récupérer la version courante du projet.
Cela se fait avec la commande checkout (abrégé en co) de SVN.
Par exemple, pour récupérer la dernière version de urpmi :
Cela va créer un répertoire trunk contenant tout le code source d'urpmi (avec la doc, les traductions, etc.).
Cette étape doit être effectué la première fois SEULEMENT. Lors du checkout, s'il existe déjà un répertoire, il sera écrasé et tout sera re-téléchargé.
[modifier] Mettre à jour sa copie locale
Une fois que la première version a été téléchargée, il est utile de récupérer de temps les nouvelles modifications. Pour cela, il n'est pas nécessaire de tout retélécharger, on utilise svn update ou up.
Il suffit de se placer dans le répertoire local et de faire :
Seules les modifications sont téléchargées, et si vous avez modifié des fichiers, les modifications locales sont préservées.
[modifier] Voir les modifications locales
Bien sûr, vous avez fait des modifications sur un fichier toute la journée, mais vous ne savez plus quoi exactement. Est-ce que cette ligne est d'origine ou pas ? C'était quoi la valeur avant ?
Cela va vous afficher les différences entre le fichier local et le dernier fichier récupéré du serveur. Si vous lancez svn diff sans nom de fichier, toutes les différences de tous les fichiers du répertoire courant seront affichées.
La sortie de svn diff est au format diff, ce qui fait qu'il peut être utiliser avec les utilitaires patch et diff, bien connus par les développeurs.
Pour créer et appliquer un fichier patch, voir la page de manuel de patch (taper "man patch").
Avec SVN, pour appliquer un fichier patch, il faut aussi connaître le numéro de version du fichier sur lequel le patch a été créé.
[modifier] Envoyer vos modifications sur le serveur
Vous avez fait du bon boulot, vous avez ajouté une fonctionnalité, enlevé un bug et vous voulez partager votre code ? C'est très simple avec Subversion.
Il suffit de faire un "commit" :
- commit peut être abrégé en ci
- sans nom de fichier, toutes les modification du répertoire sont envoyées
- l'option -m spécifie un message de commit. C'est obligatoire.
Si l'option -m est oubliée, Subversion va regarder la variable d'environnement SVN_EDITOR pour lancer un éditeur ou vous mettrez votre message. Si -m est oubliée et SVN_EDITOR est vide, alors Subversion refusera le commit.
Cela peut paraître contraignant, mais il est vraiment agréable d'avoir un trace qui explique les différentes modifications d'un fichier.
LA chose la plus importante à savoir : SEUL LE COMMIT MODIFIE LES FICHIERS DU SERVEUR. Les autres opérations se font sur les fichiers locaux.
[modifier] Ajouter/Supprimer/Déplacer des fichiers
Quand on commence un projet, il est vide, il faut ajouter les fichiers. Parfois, on se trompe ou on change d'avis et on a besoin d'enlever des fichiers obsolètes, ou de réorganiser son arborescence.
Cela se fait avec les 3 commandes :
Il faut utiliser ces commandes svn pour la gestion des fichiers. Si vous supprimez un fichier avec la commande rm au lieu de svn rm, il réapparaîtra lors du prochain svn up.
Un des avantages de Subversion par rapport à son ancêtre, CVS, c'est justement que le déplacement avec mv permet de garder l'historique du fichier.
Attention ! Ces modifications ne seront faites sur le serveur que lors du PROCHAIN COMMIT. En effet,svn add/rm/mv note les modifications locales et la transmission au serveur ne se fait que lors du commit.
[modifier] Savoir où en est
Parfois, on bosse beaucoup entre 2 commits, et on enlève/ajoute des fichiers, on modifie plusieurs fichiers dans des répertoires différents.
Pour connaître l'état courant du code grâce à status ou st :
La sortie est du style :
? pas_ds_projet A nouveau D urpmi M gurpmi C pas_daccord
- ? : le fichier n'est pas géré par SVN (par exemple, les fichiers temporaires ou de compilation)
- A : le fichier sera ajouté au prochain commit
- D : le fichier sera supprimé au prochain commit
- M : le fichier a été modifié
- C : le fichier est en conflit (voir plus bas)
[modifier] Conflits
[modifier] Cause des conflits
Modifications concurrentes et différentes de la même ligne

[modifier] Résoudre un conflit
Créations de 3 fichiers
svn resolved

[modifier] Interfaces graphiques
Ils permettent de réaliser toutes les commandes ci-dessus, de manière plus pratique.
- rapidsvn : client en gtk, par les auteurs de subversion,
- esvn : client QT, ressemble assez à rapidsvn,
- kdesvn : un autre client pour KDE.

[modifier] TODO
- Subversion chez Mandriva : en:Development/Howto/Subversion
- http://forum.club.mandriva.com/viewtopic.php?p=325239#325239
[modifier] Installer et configurer un serveur Subversion
[modifier] Installation Proprement dite
Deux paquets sont nécessaires :
- subversion-server
- subversion-tools
Le serveur est géré par xinetd, super-serveur, il lance les autres serveur à la demande. À l'installation l'utilisateur et le groupe svn sont crées. Il ne reste plus qu'à configurer pour que tout soit fonctionnel.
[modifier] Créer et ajouter un dépôt
En théorie, on peut placer son dépôt n'importe où sur son disque, mais en général, on le place dans /var/svn/ ou /svn. Créons les répertoires :
# mkdir -p /var/svn/depot1 # mkdir -p /var/svn/depot2
Nos deux répertoires ainsi crées, on va maintenant dire à subversion qu'il doit les gérer.
# svnadmin create /var/svn/depot1 # svnadmin create /var/svn/depot2
Nos deux dépôts sont crées, les fichiers de configurations, au nombre de 3 par dépôts, sont placés dans le répertoire conf/ de chaque dépôt.
[modifier] Configurer son dépôt
Trois fichiers de configuration :
- /var/svn/depot1/conf/authz
- /var/svn/depot1/conf/passwd
- /var/svn/depot1/conf/svnserve.conf
Le plus important est svnserve.conf, regardons dedans : (francisé pour plus de compréhension)
### fichier de configuration du service SVN, ### Pour configurer l'accès à ce dépôt. (Si vous voulez seulement ### utiliser les accès file:// (local) ou http:// (apache) ce fichier ### n'a pas d'intérêt.) ### Site officiel : http://subversion.tigris.org/ [general] ### Ces options controlent l'accès au dépôt pour tous utilisateurs ### 3 valeurs possibles : "write", "read" et "none". Les valeurs ### ci-dessous sont les valeurs par défaut. #anon-access = read ### Accès à l'utilisateur anonyme. #auth-access = write ### Accès à un utilisateur authentifié. ### L'option password-db contient le nom du fichier assignant les ### mots de passes. sauf si la valeur commence par un "/", ### l'url de ce fichier est relative au dossier "conf/". ### Décommentez cette ligne pour utiliser le fichier par défaut. #password-db = passwd ### L'option authz-db contient le nom du fichier gérant les authorisations ### par utilisateurs. Même remarque que précédemment avec "/" ### Décommentez cette ligne pour utiliser le fichier par défaut. #authz-db = authz ### Cette option spécifie le domaine du dépôt. ### Si deux dépôts ont le même domaine, ils auront ### le même fichier password-db, and vice versa. La valeur par défaut ### est l'uuid du dépôt. #realm = depot1
Les deux autres fichiers de conf ne sont intéressants seulement si on les utilises dans svnserve.conf. Tout d'abord authz qui permet les connections authentifiés :
Syntaxe du fichier : (un fichier d'exemple est fourni)
### Permet de créer des groupes d'utilisateurs. [groups] harry_and_sally = harry,sally ### Actions possibles : "r" signifie read, lecture, "w" pour write (écriture) et "rw" pour lecture/écriture. ### Actions dans trunk, "*" signifie Tous les utilisateurs. [trunk] * = r robert = rw ### Actions sur un autre dépôt. On retrouve notre groupe crée précédemment. [repository:/var/svn/depot2] @harry_and_sally = rw
Bien sur, pour encore plus de sécurité, il vaut mieux attacher un mot de passe à chaque utilisateur, c'est la fonction du fichier passwd :
### un utilisateur et un mot de passe par ligne [users] harry = mot_de_passe1 sally = mot_de_passe2 robert = mot_de_passe3
Le dépot est configuré, mettons le en écoute avec xinetd :
[modifier] Configuration de xinetd
Lors de l'installation de subversion-server, un fichier de conf a été automatiquement ajouté dans /etc/xinetd.d/. Il suffit d'apporter quelques modifications à ce fichier, et de relancer xinetd.
# default: off # description: svnserve is the server part of Subversion. service svnserve { disable = no port = 3690 socket_type = stream protocol = tcp wait = no user = svn server = /usr/bin/svnserve server_args = -i -r /var/svn }
Tout d'abord activez le service à l'option disable, pour plus de confort, ou pour redirection de ports, vous pouvez changer ici le port d'écoute. Changez enfin la dernière ligne, à l'option server_args, le chemin vers votre/vos dépôts.
Relancez xinetd :
Votre svn est accessible, pour vérifier, lancez cette commande :
Testez aussi en remplaçant localhost par votre IP.
Vous pouvez maintenant charger vos premières sources en les mettant dans le dossier crée par la révision 0, pour faites :
Contributeur : --Mr-Hide 29 mai 2008 à 00:25 (CEST)