Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Test de Subversion 1.0.4
(Article écrit par Mathias Parnaudeau et extrait de GuruMed.net - novembre 2004)
|
|
Qu'un projet de développement implique une ou plusieurs personnes, il est vivement conseillé d'utiliser
un outil de gestion de versions. Cela devient indispensable dès que le projet commence à grossir.
En tout cas, si l'on souhaite éviter les galères ! Qui n'a jamais fait des copies de fichiers d'un projet
donné sans se demander par la suite quelles étaient les différences entre ces copies ? Qui ne s'est jamais
dit : "Mince, mes modifications ne sont pas bonnes, j'aurais dû faire une copie pour revenir à la version
antérieure" ? Avec Subversion, ces cas ne resteront que de mauvais souvenirs.
Pour quoi faire ?
Les outils de gestion de versions proposent une assistance au programmeur soucieux de pouvoir tracer les
modifications sur son projet. Quand plusieurs personnes travaillent ensemble, leur usage s'impose encore
plus (il en va de même pour les outils de gestion de bogues). Il est alors inutile de se dire quel fichier
est bloqué et par qui, sans que les autres puissent y accéder en modification. Cette façon apparaît
comme archaïque à côté des possibilités actuelles.
Voilà un peu plus dans le détail les principales propriétés de logiciels comme Subversion ou CVS :
- Sauvegarde incrémentale : à chaque fois que des modifications sont considérées comme abouties, le
programmeur décide de les valider via une fonction "commit" qui affecte un numéro de version incrémenté
aux fichiers du projet.
- Récupération, à l'inverse, des sources d'une version ancienne du projet. Par exemple, imaginons qu'un
logiciel ne soit plus développé en 68k à partir de sa version 13, on peut retrouver tous les fichiers de
la version 12 pour corriger un bogue.
- Comparaison de fichiers : on peut demander à visualiser les différences entre deux fichiers, par exemple
si on n'a pas commenté des changements et qu'on a oubliés où ils se trouvaient.
- Intégration automatique des modifications faites par plusieurs personnes sur un même fichier :
l'intelligence du logiciel arrive à fusionner des fichiers modifiés de part et d'autre, à partir du moment
où les changements n'ont pas été opérés au même endroit. Dans ce dernier cas, il faut réconcilier à la main
mais ça évite la plus fastidieuse des opérations !
En plus de tout cela, ce procédé permet d'avoir une sauvegarde à jour et éventuellement sur une machine
distante, ce qui augmente la sécurité. Bien sûr, il est aussi possible à tout moment d'obtenir simplement
l'historique des modifications ou le statut de chaque fichier local du projet.
Si l'on parle de termes "local" et "distant", c'est que Subversion (et ses équivalents) fonctionnent suivant
le principe du client-serveur. Chaque développeur utilise un client depuis son ordinateur pour envoyer des
commandes à un serveur qui, lui seul, gère la base de fichiers du projet. Pour cela, le serveur accède au
répertoire qui contient d'une manière ou d'une autre les sources et des fichiers de configuration. Ce
répertoire est appelé dépôt ou, en anglais, "repository".
Ces principes généraux s'appliquent à tous ces outils de gestion de versions. Jusqu'ici, l'outil le plus
connu et employé dans la quasi-totalité des projets Open Source se nomme CVS. Le site Sourceforge
l'utilise par exemple pour les projets qu'il héberge. Mais CVS n'est pas le seul. Et le dernier à faire
parler de lui et qui a des chances de s'imposer est bel et bien Subversion.
Atouts de Subversion
Il ne se cache pas de proposer les mêmes fonctionnalités que CVS, son illustre aîné, mais souhaite
pourtant clairement s'en distinguer, par les fonctionnalités et l'approche qu'il offre. Subversion
reprend les principes classiques mais en repartant sur des bases saines et en apparaissant plus simple
et plus logique.
Avant tout, Subversion laisse une plus grande liberté dans la manipulation des fichiers... et des répertoires,
ce dernier point constituant une nouveauté ! Ainsi, sur un renommage, un déplacement ou une suppression
de fichier, CVS se défendait de ne pouvoir le faire en prétextant que cela cassait l'historique du projet.
En effet, si on supprime un fichier dans le dépôt, on perd la trace sur ce fichier. Quoique. On comprend
la raison mais CVS aurait dû pallier à ça en interne pour que ces opérations soient faisables par l'utilisateur.
Par une approche différente, Subversion autorise toutes ses actions !
Un autre avantage de Subversion dans sa gestion des fichiers est la prise en compte des fichiers binaires
(icônes, image, document...) et leur reconnaissance automatique. Cela permet le stockage de tous les
fichiers d'un projet et pas seulement ceux liés au développement. Un tel fonctionnement avec CVS impliquait
de placer manuellement un drapeau spécial sur chaque fichier.
Même utilisé en ligne de commandes, la manipulation de l'outil client (SVN) est simple et ne requiert pas
de paramétrage. Les actions possibles sont explicites et en plus bien documentées dans un fichier PDF de
référence, librement téléchargeable. Le client peut se connecter de plusieurs manières au serveur, soit
en spécifiant l'adresse IP locale (communication avec le serveur en arrière-plan) et le répertoire du projet,
soit via une connexion HTTP. Ce dernier cas est rendu possible car Subversion est livré avec un module
destiné au serveur Apache.
Globalement, Subversion est plus clair dans ses actions et donne du sang neuf par rapport à CVS, mettant
en place des concepts importants, comme le "commit" (envoi des modifications) qui s'applique à l'ensemble
des fichiers. Ainsi, on ne valide qu'au moment où on obtient une cohérence globale et pas uniquement quand
la compilation d'un fichier réussit dans son coin.
Pour qui ?
Subversion offre donc confort et puissance dans la gestion de projet, tout en restant simple et logique.
Les bénéficiaires sont nombreux et ne s'arrêtent pas aux seuls développeurs. D'autres peuvent ainsi partager
l'accès simultané de fichiers entre plusieurs personnes, pour consultation mais aussi modification. Cela
concerne les documents par exemple : combien de fois on en vient à se demander qui a la "bonne version"
d'un fichier ou s'il est possible d'avoir la documentation utilisateur de telle date ?
Les membres d'une équipe peuvent ainsi travailler en même temps sur des parties différentes d'un document.
De plus, cette gestion permet au passage la sauvegarde et l'archivage sur un serveur distant ! Si des
changements ont lieu dans des endroits différents d'un fichier, Subversion les prend en compte automatiquement.
Sinon, il y a besoin d'une intervention manuelle mais c'est un moindre mal, l'outil ne peut pas non plus
tout deviner ! Il y a alors conflit et une des personnes doit corriger le fichier puis dire à Subversion
que le conflit est résolu, un envoi de modification redevient possible en toute confiance.
Chacun peut aussi s'approprier Subversion avec un minimum d'efforts. La mise en place n'est pas difficile
mais il est quand même conseillé d'avoir un serveur sous Linux. Par contre, encore une fois, les outils
s'utilisent en lignes de commandes... jusqu'à ce qu'une interface soit conçue (avis aux courageux !).
Ce n'est franchement pas gênant à l'usage.
Pour améliorer encore l'accessibilité, la documentation est très bien faite, au format PDF et... gratuite !
Le contenu est pourtant exactement celui du livre vendu dans le commerce. Il faut juste ne pas détester
lire sur l'écran et... comprendre l'anglais (le livre en français vaut 38 euros, aux éditions O'Reilly).
En pratique
A présent, voyons comment on met en oeuvre un serveur et un client Subversion. Ceci est basé sur ma
propre expérience, acquise pendant quelques mois, période pendant laquelle j'ai mis plusieurs de mes
projets en place.
Tout commence bien sûr par l'installation. Du côté serveur d'abord. Sous Linux Debian, les paquets
sont facilement récupérables via une recherche dans l'outil graphique Synaptic. L'outil serveur (appelé "daemon"
de manière générale) se lance ainsi :
Toujours sur le poste Linux, le projet doit être créé : "svnadmin create nom_du_projet". Un répertoire est
créé ainsi que plusieurs sous-répertoires, dont le dépôt qui stockera les données de toutes les versions
du projet.
Un des sous-répertoires nommé "conf" contient un fichier de paramétrage à modifier absolument. C'est lui qui
permettra aussi de déterminer les autorisations en lecture ou écriture sur le projet, en gérant notamment
les comptes utilisateurs et leur mot de passe associé.
Le client peut alors être testé. On commence par importer le projet en cours dans le dépôt sur le serveur :
Svn import svn://192.168.0.13/home/mathias/svn/nom_du_projet
|
Ensuite, toutes les opérations sont possibles : ajouter ou supprimer des fichiers, voir le journal des opérations
effectuées, visualiser les différences entre deux versions d'un même fichier, etc. Ces commandes sont
extrêmement simples à utiliser. Pour ajouter un nouveau fichier juste créé en local : "svn add fichier1.c".
La commande "update" est très souvent utilisée et elle sert à mettre à jour les fichiers locaux en fonctions
des fichiers du dépôt qui ont été validés (commit, même terme que pour les bases de données).
En cas de problème, il est possible de vérifier son fonctionnement avec un projet en ligne. Dans ce cas, on
procède à une opération de vérification (alias "checkout", on peut aussi utiliser son diminutif "co") pour
récupérer l'ensemble des fichiers et créer une copie locale du projet qui servira de base de travail. Par
exemple, pour récupérer les sources de Samba, la commande est la suivante :
svn co svn://svnanon.samba.org/samba/trunk samba-trunk
|
Toutes les commandes sont documentées et on prend vite le pli. Le statut des fichiers, notamment après mise à
jour, est également assez clair :
- U : mise à jour de la copie locale.
- G : des modifications avaient été apportées sur le fichier local et SVN a pu intégrer les modifications
du dépôt.
- C : idem mais les modifications provenant du dépôt provoquent un conflit avec les changements apportés
en local.
- etc.
Un avant-goût est donné, j'espère qu'il vous aura donné l'envie d'expérimenter.
Adoption
Après plusieurs mois d'utilisation (serveur Linux/Debian et client MorphOS), je suis extrêmement satisfait
de Subversion et enthousiaste de ne plus avoir à utiliser CVS, performant mais d'une approche moins naturelle.
Les projets CVS peuvent d'ailleurs être migrés vers Subversion.
Les outils du côté client sont disponibles pour MorphOS, AmigaOS 4 et même AmigaOS 68k depuis peu. Ils
devraient donc rejoindre les incontournables de votre boîte à outils du développeur : amuidiff, splint,
mpatrol, éditeur hexadécimal, etc. Outre les facilités apportées pour le développement à plusieurs, les bénéfices
peuvent aussi être obtenus en l'utilisant comme serveur de fichiers, outil de sauvegarde, etc.
Rappelons quand même que sa fonctionnalité principale est de modifier des fichiers sources en même temps
par des personnes différentes.
Rien que sur cet aspect, Subversion ne se limite pas seulement aux sources de programmes : ceux qui
rédigent de la documentation peuvent tout à fait travailler à plusieurs dans ces conditions, les modifications
de chacun étant prises en compte automatiquement.
Nom : Subversion 1.0.4.
Développeurs : Apache Software Foundation.
Genre : logiciel de gestion de versions.
Date : 2004.
Configuration minimale : Amiga OCS, 68020, 2 Mo de mémoire, AmigaOS 2.0.
Licence : Apache.
Téléchargement : Aminet.
|
|
