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.

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).

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.

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.

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é.

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.

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.