Un système de gestion de versions est un logiciel qui permet à plusieurs développeurs de partager une base de code sans se marcher sur les pieds, et en gardant une mémoire des développements passés. Même si on développe seul, utiliser un tel système est pratique, parce qu'il permet de suivre ce qu'on fait.

Un système comme Subversion fonctionne sur un principe client-serveur. Un ordinateur, quelque part (moi j'utilise les services de all2all), stocke la base de code dans toutes ses versions successives. Et sait répondre à des sollicitations définies par le protocole de Subversion, en faisant tourner la partie serveur du logiciel Subversion. Symétriquement, j'installe sur mon ordinateur la partie client du logiciel, qui va dialoguer avec le serveur pour récupérer la base de code et transmettre les modifications que j'y ferai. 

La première opération consistera à importer sur mon ordinateur une copie locale (en anglais working copy) de la base de code. C'est sur cette version locale que je travaillerai. Et à chaque fois que je jugerai que les modifications que j'y ai apportées forment un tout cohérent, je les enverrai au serveur.

Dans le développement d'un site web, la base de code est constituée de l'ensemble des fichiers qui constituent le site : fichiers HTML, fichiers PHP, feuilles de styles, images, animations Flash, fichiers de configuration, etc. Suivant le principe énoncé plus haut, cette base de code est stockée sur le serveur Subversion, et chaque développeur en a une copie locale.

En outre, il est pratique de disposer de la partie client de Subversion sur l'ordinateur hébergeant le site web. Une simple commande Subversion exécutée sur cet ordinateur (le serveur web) permet d'y installer en un minimum de transferts et avec une fiabilité totale la dernière version du site.

Le cauchemar des versions

Subversion existe dans la nature essentiellement dans les versions 1.4, 1.5 et 1.6. Qui ne sont pas totalement compatibles entre elles. Et comme on parle de gérer le fruit de notre travail, on ne rigole pas avec des incompatibilités qui risqueraient de véroler la base de code...

Ces temps-ci, je transfère mon environnement de travail d'un autre ordinateur vers mon Mac. Subversion en fait partie. Il se trouve que Subversion est déjà présent sur les Macs, en version 1.4. Mais voilà : j'ai déjà des bases de code gérés sur un serveur Subversion, sur lesquelles j'ai déjà travaillé (depuis l'autre ordinateur) avec un client Subversion 1.5. Et par dessus le marché, je m'aperçois que je déploie déjà ce code sur des hébergements web en y ayant installé un client Subversion 1.4.

Par quel miracle mes bases de code n'ont-elles pas été vérolées jusqu'alors ? Dois-je réinstaller les clients Subversion sur mes hébergements ? Quelle version puis-je utiliser (éventuellement installer) sur mon Mac ? Et au fait, quelle est la version de Subversion qui tourne sur le serveur d'all2all ?

Un réveil heureux

C'est Samuel (merci Samuel) qui m'a donné la réponse, qui tient en deux bonnes nouvelles. D'une part, toutes les versions de la partie serveur de Subversion sont compatibles avec toutes les versions de la partie client. (Certes, à la réflexion, on se dit que le système n'aurait pas été très viable sinon. Mais bon.) Donc peu importe la version de Subversion qui tourne sur le serveur.

D'autre part, la seule contrainte côté client est que tous les clients Subversion qui gèrent une même copie locale soient dans la même version. En pratique, cela suggère qu'une seule et même version de Subversion soit installée et utilisée sur un ordinateur donné. Mais la différence de versions entre mon ancien client Subversion, mon futur client sur le Mac, et le client sur les hébergements web, est sans importance.