Profitez des offres Memoirevive.ch!
Subversion grâce à Versions

Nous allons nous intéresser aujourd'hui à une application prometteuse et très agréable à utiliser répondant au doux nom de Versions. Pourquoi ce nom? C'est très simple: Versions est un client subversion.

Sub... quoi? Qu'est-ce que c'est?

Je vous l'accorde, tout le monde ne sera pas intéressé par subversion, mais si je vous en parle tout de même aujourd'hui, c'est que je suis persuadé que cela ne touche pas qu'un nombre réduit d'informaticiens scotchés à leur écran, notamment grâce au logiciel Versions que l'on va découvrir.

Subversion (abrégé svn) est un système de gestion de versions, successeur de CVS (Concurrent Versions System) si le mot vous dit quelque chose. Par gestion de versions, on entend la possibilité pour diverses personnes de partager des données, de les éditer de manière collaborative et de suivre l'évolution du contenu au fil des modifications.

Prenons l'exemple d'une petite équipe de développeurs se lançant dans l'écriture d'une nouvelle application. Chacun se verra confier le développement d'une partie de l'application. L'idéal serait donc de pouvoir travailler autour d'un projet d'application commun, où chaque développeur peut modifier les fichiers qui le concernent et récupérer les modifications faites par les autres.

C'est en gros ce que permet subversion. Le projet de base est importé sur un serveur unique. Chaque développeur récupère alors, grâce à svn, une version locale du projet. Par la suite, toutes les modifications apportées localement pourront être enregistrées sur le serveur collaboratif. Si d'aventure des modifications sont incompatibles (deux personnes modifient une même portion de code de manière différente), svn permettra aux utilisateurs de résoudre les conflits de manière propre et adéquate.

Grâce à ce système, il est donc possible d'une part de travailler à plusieurs sur un même projet, et d'autre part d'avoir un suivi de l'évolution de son travail, puisque svn permet de remonter le temps et revenir à une version antérieure de son projet.

Si le travail collaboratif paraît évident pour des programmeurs ou concepteurs de sites web par exemple, la possibilité de suivre son travail pas à pas tout en s'assurant une copie de sauvegarde de ses fichiers suscitera peut-être l'intérêt d'un plus large public.

En effet, grâce à subversion, nous avons les bases pour créer une sorte de Time Machine à distance, les fichiers pouvant être conservés sur un serveur relié à Internet. Cela dit, svn est avant tout un outil d'informaticiens, pour qui la ligne de commande dans un terminal n'a pas l'effet rébarbatif qu'elle peut avoir sur le commun des mortels! C'est là qu'interviennent les différents clients svn arborant une belle interface graphique permettant à tout un chacun d'utiliser ce logiciel de manière relativement simple.

Je vous épargnerai donc l'utilisation de svn via le Terminal et me concentrerai sur un logiciel qui était en version beta depuis quelques temps et qui vient de passer en version finale: Versions. Son interface soignée et élégante en font un très bon client subversion, se démarquant de ce que l'on avait jusqu'à maintenant.

Versions adopte en effet parfaitement les courbes des applications créées pour Leopard et revêt svn d'une de ses plus belles robes. Les habitués de svn via la ligne de commande trouveront en Versions une manière efficace de naviguer dans la hiérarchie de ses fichiers, consulter l'historique et recourir à certains outils de svn alors que les novices auront la possibilité d'exploiter la puissance de svn de façon intuitive, sans devoir en plus s'habituer à un environnement au premier abord austère.

Et pour les personnes qui se poseraient la question, il est tout à fait possible de mélanger les deux façons de gérer un même projet, en utilisant une fois le Terminal et une autre fois Versions. C'est d'ailleurs ce que je fais moi-même, selon ce que je veux faire.

Gérer ses projets avec subversion

Qui dit client subversion dit d'abord subversion: il faut en effet que le logiciel soit installé sur sa machine pour que le client puisse en tirer profit. Utilisateurs de Leopard, bien vous en a pris puisque svn est installé par défaut sur le système (dans /usr/bin/svn pour les curieux). Pour les autres, svn est disponible en open source ici.

Dans l'introduction, j'ai parlé de conserver les données sur un serveur unique. Vous l'aurez donc compris, il faut pouvoir placer son projet sur un serveur, et pas n'importe lequel puisque celui-ci doit supporter svn.

Votre propre machine pourrait faire l'affaire; si vous êtes seul à travailler sur ce projet et que vous voulez simplement avoir un suivi de votre travail, vous pouvez tout à fait créer un dépôt (terme employé par svn pour l'endroit où l'on stocke les données) en local.

Si vous désirez avoir accès à vos fichiers depuis n'importe où ou les partager avec des collaborateurs, il faudra alors trouver une solution sur Internet. Il existe de nombreux serveurs svn payants (un peu comme un hébergement de sites web), à des prix variant selon les services offerts, et l'on en trouve quelqu'uns de gratuits (Assembla ou OpenSVN par exemple).

Une fois tous les éléments nécessaires en place, vous voilà donc prêt à utiliser subversion, et plus exactement Versions. L'idée bien sûr est que vous ayez un projet à suivre, quel qu'il soit. S'il s'agit du code d'une application ou d'un site web, vous pourrez suivre les modifications du code lui-même à l'intérieur des fichiers. S'il s'agit d'un projet de photos, vous garderez l'historique des différents fichiers si de nouvelles versions viennent remplacer les anciennes. Ou s'il s'agit de la rédaction d'un article, vous pourrez agir tout comme s'il s'agissait de code, en visualisant l'évolution de l'écriture de votre texte.

Avant de nous attaquer à Versions, voyons d'abord ce qu'il est possible de faire avec subversion d'une manière générale, afin de comprendre les outils proposés par Versions.

Lorsque l'on désire gérer un projet via subversion, il faut tout d'abord placer les données sur le serveur. On parle alors d'importer (import en anglais) le projet sur le dépôt.

Une petite note peut-être en passant sur la structure à adopter concernant un projet. S'il n'y a absolument aucune obligation d'avoir telle ou telle hiérarchie au sein de son répertoire de base, il est courant de séparer le répertoire racine de la sorte:

  • un dossier trunk: il s'agit du tronc commun, autrement dit le développement actuel du projet
  • un répertoire branches: copies du trunk permettant un développement plus abouti de nouvelles fonctionnalités par exemple
  • un dossier tags: les versions "releases"

Quand un projet se trouve sur le serveur, il faut que chacun le récupère sur sa machine de travail. Il s'agit là de faire ce que l'on appelle un checkout. Seul un projet récupéré de la sorte sera géré par subversion; entendez par là que le fait d'importer un projet ne sert qu'à placer les données sur un serveur, le projet en local ne sera pas géré par svn. Pour cela, il faut obligatoirement effectuer un checkout.

Diverses fonctionnalités permettent d'ajouter ou retirer des dossiers ou fichiers de son projet. Par exemple, un fichier retiré ne fera plus partie de la version actuelle mais pourra toujours être récupéré dans une version antérieure (tout comme Time Machine vous permet de récupérer un supprimé).

Lorsque l'on a apporté des modifications à son travail, il convient de mettre à jour les données en question sur le serveur; les modifications ne sont pas mise à jour "en direct", c'est à l'utilisateur de choisir quand il veut le faire. L'idée est que le développeur décide du moment où les changements apportés sont assez significatifs pour que tout le monde puisse en bénéficier. L'action d'envoyer les mises à jour sur le serveur est appelée commit.

De l'autre côté, les mises à jour du projet sur le serveur ne sont pas automatiquement reflétées chez chaque utilisateur. C'est à chaque collaborateur de dire "je veux mettre à jour ma version locale d'après le contenu du serveur". Il s'agit là d'opérer un update. Grâce au système de versions, il est tout à fait possible de mettre à jour sa copie locale d'après une ancienne version, par exemple si le travail effectué entre-deux est abandonné.

Si chacun peut faire des modifications dans son coin et les mettre à jour quand il veut, il est fort à parier que de temps à autre, deux personnes modifient une même portion du projet de manière différente et envoient leur travail sur le serveur. Au moment de mettre à jour sa copie locale, deux versions sont alors disponibles depuis la dernière mise à jour: il y a ce que l'on appelle un conflit de versions. Subversion permet de résoudre les conflits de la sorte: soit en choisissant l'un des deux fichiers, et tant pis pour l'autre, soit en combinant les versions de la manière qu'il convient et déclarer le conflit comme résolu. Seule cette version finale sera alors gardée.

Utilisation de Versions

Après vous avoir exposé les principes de subversion (vous me suivez toujours?), parlons (enfin) de Versions! Je ne vais pas vous détailler tous les aspects du logiciel, mais voyons plutôt quels sont les intérêts de cette application.

Versions permet de gérer ses dépôts (projets) sous forme de liste à la manière du Finder ou d'iTunes; chaque dépôt est un signet que l'on crée en prenant soin de remplir les informations nécessaires à la récupération des données (adresse du serveur, login, mot de passe,…). L'utilisateur a donc un aperçu rapide de ses projets gérés par subversion.

Checkout, dans la barre d'outils, permet de créer une version locale gérée par subversion d'un dépôt, ou d'un dossier en particulier d'un dépôt. Le dossier est alors créé à l'endroit de son choix sur le disque dur et s'affiche juste en-dessous du nom du dépôt dans Versions. On remarque alors qu'il est possible d'avoir les informations d'une part sur le dépôt lui-même, en le sélectionnant dans la liste, et d'autre part sur la copie locale si celle-ci est sélectionnée.

liste
La liste des dépôts avec leur copie locale juste en-dessous.

Selon l'élément sélectionné dans la liste, les boutons Timeline, Browse et Transcript affichent les informations soit d'un dépôt soit d'une copie locale.

Timeline affiche chaque mise à jour effectuée par l'un des collaborateurs et liste les fichiers modifiés. Il est alors aisé de voir les modifications apportées par chacun, ce d'autant plus qu'il est possible de spécifier un commentaire lorsque l'on met à jour le serveur (commit).

carte
Pour chaque mise à jour, on aperçoit la date, le numéro de version, l'utilisateur, son commentaire et les fichiers modifiés.

Browse permet de naviguer dans son projet comme on peut le faire dans le Finder. Pour chaque fichier, le numéro de version (la version de la dernière modification), la date et l'utilisateur qui a enregistré cette version sont affichés. Si un dossier local est sélectionné, l'utilisateur verra des annotations indiquant que le fichier a été modifié, ajouté, supprimé ou déplacé depuis la dernière mise à jour.

browse
La liste des fichiers d'un dépôt.

Il est possible d'ajouter ou supprimer un fichier grâce aux boutons de la barre d'outils. Une telle action sur un projet local ne prendra effet sur le serveur qu'une fois une mise à jour (update) effectuée par l'utilisateur. Par contre si cela est réalisé sur un fichier du dépôt, une nouvelle version est directement créé, contenant la modification effectuée.

toolbar
La barre d'outil.

Toujours dans cette même barre, on retrouve les actions standards de subversion, à savoir la mise à jour de sa copie locale (update), l'envoi de ses données sur le serveur (commit), la récupération d'un dépôt en local (checkout) ou la possibilité de revenir à une version antérieure (revert).

Divers outils permettent également de comparer les différences entre sa copie locale et celle du serveur ou entre différentes versions. Ceux-ci s'avèrent utiles en cas de conflit, afin de savoir exactement quelle version garder, ou simplement afin de se rendre compte rapidement des modifications effectuées par quelqu'un d'autre sur un fichier que l'on traite.

Pour connaître exactement l'évolution d'un fichier ou d'un dossier, il faut consulter son historique. Différents critères permettent alors d'en savoir plus sur telle ou telle version de l'élément consulté.

historique
L'historique d'un dossier, avec tous les changements apportés à celui-ci au cours du temps.

Enfin, l'inspecteur affiche les propriétés et informations d'un élément sélectionné. Les informations ne sont rien d'autre qu'un résumé global du fichier ou du dossier. L'onglet propriétés permet quant à lui de spécifier diverses propriétés subversion (on s'en serait douté); celles-ci définissent un certain comportement que subversion doit adopter par rapport au fichier.

Ainsi, la popriété ignore signifie que l'élément possédant cette propriété contient une liste de fichiers ou dossiers que l'utilisateur ne veut pas traiter par subversion. L'exemple ci-dessous montre que le dossier build du répertoire ExperienceApp doit être ignoré, ce qui veut dire que ce dossier sera bien présent sur la copie locale mais ne sera jamais traité par svn et ne se retrouvera donc pas sur le serveur. Cela permet notamment à chaque utilisateur d'avoir ses propres fichiers qui ne seront pas partagés.

inspecteur
L'inspecteur affichant les propriétés et informations d'un dossier.

Pour les curieux, je suis passé au travers des exemples sans jamais mentionner quel est le contenu réel de mon projet, mais vous aurez sans doute remarqué qu'il s'agit là d'une application pour iPhone, créée à l'aide de Xcode bien sûr. Xcode gère également subversion, mais il n'apprécie pas trop le dossier build, modifié à chaque compilation de l'application. Comme ce dossier peut être créé d'après les sources et n'a donc pas besoin d'être partagé, il est tout simplement ignoré.

Conclusion

Même si les connaisseurs de subversion ont sans doute déjà leur(s) outil(s) favori(s), je conseille fortement de tester cette application dédiée. Si son prix de 39euros peut paraître élevé, il est possible de la tester durant une vingtaine de jours et de se faire donc une bonne idée des capacités de l'application. Dans bien des cas, Versions permet un plus grand confort par rapport à la ligne de commande ou à d'autres clients svn et une meilleure vision de ses projets. De plus, comme je l'ai déjà dit, il est tout à fait possible de combiner les outils.

Quant aux autres, si vous vous demander encore quel est le moyen de gérer différentes versions d'un travail ou que vous passez votre temps à compresser vos dossiers en les renommant "projet_v1, projet_v2,…", jetez-vous sur cette application et testez-la immédiatement, vous trouverez peut-être là un moyen relativement simple et efficace de suivre l'évolution de votre travail.

14 commentaires
1)
Ölbaum
, le 25.11.2008 à 02:15
[modifier]

C’est quand-même dommage de ne voir se pointer des clients Subversion pour Mac qui tiennent la route qu’au moment où tout le monde se met à Git ou Mercurial. Depuis que j’utilise ce dernier je ne peux plus sentir Subversion, de la même façon que je n’ai plus pu blairer CVS quand j’ai commencé à utiliser Subversion, d’ailleurs.

“CVS init nom_du_projet nom_du_developpeur nom_de_la_belle_mere age_du_capitaine nombre_au_hasard_mais_PAS_42”, ça rappelle quelque chose à quelqu’un ?

2)
Thibaud
, le 25.11.2008 à 08:00
[modifier]

+1 pour Git, quasiment toute la communauté Ruby On Rails y est passé. Désolé mais Subversion c’est déjà du passé :-)

3)
Franck Pastor
, le 25.11.2008 à 08:05
[modifier]

+1 pour Git, quasiment toute la communauté Ruby On Rails y est passé. Désolé mais Subversion c’est déjà du passé :-)

Z’auraient pu choisir un autre nom que Git (qui veut dire « sale type », en gros, en anglais). C’est limite contre-pub ! :-)

Moi, je vais me mettre à Subversion, puisqu’un de mes collègues me le conseille fortement. On verra bien pour les autres ensuite. Merci pour ce test, 6ix. Si j’ai du mal avec svn au Terminal, je sais qu’il y aura alors une interface graphique pour m’aider :-)

4)
chtito
, le 25.11.2008 à 08:13
[modifier]

Je suis totalement d’accord avec le précédent commentaire de Ölbaum. Ça fait maintenant bien un an que mercurial, git et les autres sont bien implantés. Subversion n’a vraiment plus aucun intérêt, à mon avis. Moi non plus je ne peux plus le sentir.

Malheureusement il n’y a pas encore de client mercurial/git pour mac. D’un autre côté c’est tellement plus simple que subversion qu’on en a à peine besoin…

Enfin, dommage que certains développeurs ne sentent pas le vent tourner et continuent à développer pour subversion…

5)
François Suter
, le 25.11.2008 à 08:43
[modifier]

SVN est peut-être en voie de ringardisation, mais il est encore fortement implanté. Quand on bosse avec des logiciels open source, difficile d’éviter d’utiliser des dépôts SVN.

Pour ma part, je viens d’adopter avec beaucoup de bonheur Cornerstone , comme client SVN pour Mac.

6)
Robin
, le 25.11.2008 à 09:06
[modifier]

Attention, utilisateur SVN, ne testez pas Version!! Ou il vous en coûtera 39 euros. J’ai suivi le projet depuis pas mal de temps en beta, et je ne peux plus m’en passer. L’interface est vraiment très confortable et je n’arrive pas à revenir à SVNX qui est gratuit. Bravo aux développeurs.

7)
François Cuneo
, le 25.11.2008 à 09:13
[modifier]

Content de voir que ce genre de choses existe sur nos Macs.

Désolé de voir que je suis complètement dépassé dans ce domaine…

Bouhouhouhou…

8)
popey
, le 25.11.2008 à 14:04
[modifier]

Je vais aller contre plusieurs personnes dans ce fil : non, svn n’est pas obsolète. Le modèle de fonctionnement est très différent de celui de Git ou Mercurial, c’est une approche différente de la gestion de sources. Une approche ne rend pas l’autre obsolète. Un des gros avantages de SVN (ce pour quoi je l’utilise) est justement le fait qu’il soit centralisé. Ca simplifie énormément ma stratégie de sauvegarde !

Pour en revenir au sujet de l’article, effectivement, versions est un client très agréable pour subversion. De mon côté, je ne l’adopte pas pour une seul raison : son prix. Les projets avec lesquels j’utilise svn s’appuient pour la grande majorité sur xCode ou Eclipse. xCode propose un client subversion (un peu simpliste, mais pratique pour les opérations de base), et Eclipse propose un client ultra complet.

Pour quelques opérations avec les projets xCode, je me retrouve en ligne de code, mais c’est trop rare pour justifier une dépense de 39 euros.

Je précise que c’est un point de vu personnel : pour mon utilisation, ce n’est pas rentable. Ca ne veux pas dire du tout que le logiciel ne vaut pas les 39 euros demandés !

9)
6ix
, le 25.11.2008 à 17:01
[modifier]

Effectivement, on entend de plus en plus parler de Git. Je dois avouer que pour ma part, je n’ai encore jamais eu l’occasion de tester, d’autant que svn reste très utilisé. Mais je compte bien regarder cela de plus près!

Quant à Version, c’est sûr qu’il y a moyen de faire avec Xcode et Eclipse, que j’utilise également, et le prix peut paraître un poil élevé selon l’utilisation de svn. Cela dit, c’est un bon moyen d’avoir un aperçu de tous ses projets au sein d’une unique interface.

10)
Noé Cuneo
, le 25.11.2008 à 20:11
[modifier]

+1 pour git aussi! Le fait de pouvoir séparer commit et envoi sur le serveur est un tel bonheur! Typiquement, je bosse souvent dans le train, et j’apprécie beaucoup de pouvoir profiter des avantages d’un tel gestionnaire hors ligne!

11)
POG
, le 25.11.2008 à 21:07
[modifier]

Salut 6ix,

Serait-il possible de faire un autre article plus “technique” comment utiliser subversion avec des fichiers textes ? L’idée c’est de trouver un moyen détourné de stocker les fichiers Latex ou autre. Est-ce que cela a du sens ou pas ?

Bonne soirée et encore merci pour cet article.

PO

13)
gbuma
, le 26.11.2008 à 09:54
[modifier]

J’ai utilisé “cvs” puis j’ai adoré “svn” (utilisé à travers svk, faut pas pousser). Et puis j’ai découvert git.

Il y a une version avec interface et tout: gitx (http://gitx.frim.nl/).

Je garde svn pour la distribution, le deployement.

Donc maintenant, j’utilise git pour travailler, versionner, brancher, etc et c’est le rêve. Et puis je fais une synchronisation sur le serveur subversion avec svk.

J’ai le meilleur des deux mondes: un outil puissant pour gérer mes commits et les contributions (git) et un serveur centralisé avec la version stable pour facilement identifier une version (numéro de révision) avec subversion.

G

14)
alienlebarge
, le 27.11.2008 à 17:57
[modifier]

Est-ce que qqun a déjà tenté d’utiliser Verions et/ou Coda avec Google Code ?

Merci pour l’article ; ) super