Modèles de gestion de version

Tous les systèmes de contrôle de version doivent résoudre le même problème fondamental : comment le système permettra-t-il aux utilisateurs de partager l'information, mais les empêchera accidentellement de se marcher sur les pieds ? Il est trop facile pour les utilisateurs d'écraser accidentellement les changements de chacun sur le dépôt.

Le problème du partage de fichier

Considérons ce scénario : supposons que nous avons deux collaborateurs, Harry et Sally. Ils décident chacun d'éditer le même fichier du dépôt en même temps. Si Harry sauvegarde ses changements sur le dépôt d'abord, il est possible qu'ensuite (quelques moments plus tard) Sally puisse accidentellement les écraser avec sa propre nouvelle version du fichier. Tandis que la version d'Harry du fichier ne sera pas perdue pour toujours (parce que le système se rappelle chaque changement), les changements qu'Harry a fait ne seront pas dans la version plus récente du fichier de Sally, parce qu'elle n'a jamais vu les changements d'Harry pour commencer. Le travail d'Harry est effectivement encore perdu - ou du moins manquant de la dernière version du fichier - et probablement par accident. C'est certainement une situation que nous voulons éviter!

Figure 2.2. Le problème à éviter

Le problème à éviter

La solution Verrouiller-Modifier-Déverrouiller

Beaucoup de systèmes de contrôle de version utilisent le modèle verrouiller-modifier-déverrouiller pour aborder ce problème, qui est une solution très simple. Dans un tel système, le dépôt ne permet qu'à une seule personne de changer un fichier à la fois. D'abord Harry doit verrouiller le fichier avant qu'il ne puisse commencer à y faire des changements. Le verrouillage d'un fichier s'apparente alors à l'emprunt d'un livre dans une bibliothèque ; si Harry a verrouillé un fichier, alors Sally ne peut pas le modifier. Si elle essaye de verrouiller le fichier, le dépôt refusera la requête. Tout qu'elle peut faire est lire le fichier et attendre qu'Harry finisse ses changements et relâche le verrou. Dès qu'Harry déverrouille le fichier, son tour est fini, et Sally peut alors prendre son tour en le verrouillant et en y apportant ses modifications.

Figure 2.3. La solution Verrouiller-Modifier-Déverrouiller

La solution Verrouiller-Modifier-Déverrouiller

Le problème avec le modèle "verrouiller-modifier-déverrouiller" est qu'il est un peu restrictif et devient souvent un barrage pour les utilisateurs :

  • Le verrouillage peut causer des problèmes administratifs. Parfois Harry verrouillera un fichier et ensuite l'oubliera. En attendant, parce que Sally attend toujours pour éditer le fichier, ses mains sont liées. Et ensuite Harry va en vacances. Maintenant Sally doit appeler un administrateur pour relâcher le verrou d'Harry. La situation se finit en causant beaucoup de retard inutile et de temps gaspillé.

  • Le verrouillage peut causer une sérialisation inutile. Et si Harry édite le début d'un fichier texte et Sally veut simplement éditer la fin du même fichier ? Ces changements ne se chevauchent pas du tout. Ils pourraient facilement éditer le fichier simultanément et aucun grand mal n'arriverait, à supposer que les changements aient été correctement fusionnés ensemble. Ils n'ont aucun besoin de prendre leur tour dans cette situation.

  • Le verrouillage peut créer un faux sentiment de sécurité. Disons qu'Harry verrouille et édite le fichier A, tandis que Sally verrouille et édite le fichier B en même temps. Mais supposons qu'A et B dépendent l'un de l'autre et les changements faits à chacun sont sémantiquement incompatibles. Soudainement A et B ne marchent désormais plus ensemble. Le système de verrouillage était impuissant à empêcher le problème - encore il a fourni d'une façon ou d'une autre un sentiment de fausse sécurité. C'est facile pour Harry et Sally de s'imaginer qu'en verrouillant les fichiers, chacun commence une tâche sûre, isolée et les interdit ainsi de discuter de leurs changements incompatibles dès le début.

La solution Copier-Modifier-Fusionner

Subversion, CVS et les autres systèmes de contrôle de version utilisent un modèle copier-modifier-fusionner comme une alternative au verrouillage. Dans ce modèle, le client de chaque utilisateur lit le dépôt et crée une copie de travail personnelle du fichier ou du projet. Les utilisateurs travaillent alors en parallèle, modifiant leurs copies privées. Finalement, les copies privées sont fusionnées ensemble dans une version nouvelle, finale. Le système de contrôle de version aide souvent avec la fusion, mais en fin de compte un être humain est responsable pour qu'elle se produise correctement.

Voici un exemple. Disons qu'Harry et Sally ont chacun une copie de travail du même projet, extrait du dépôt. Ils travaillent en même temps et modifient localement le même fichier A. Sally sauvegarde ses changements dans le dépôt d'abord. Quand Harry essaie de sauvegarder ses changements, le dépôt l'informe que son fichier A est périmé. Autrement dit, dans le dépôt, ce fichier A a été modifié depuis qu'il a été extrait. Donc Harry demande à son client de fusionner les nouveaux changements du fichier A du dépôt avec sa copie de travail. Il y a des chances que les changements de Sally ne se chevauchent pas avec les siens ; ainsi une fois qu'il a les deux changements intégrés, il sauvegarde sa copie de travail sur le dépôt.

Figure 2.4. La solution Copier-Modifier-Fusionner

La solution Copier-Modifier-Fusionner

Figure 2.5. ...Suite du modèle Copier-Modifier-Fusionner

...Suite du modèle Copier-Modifier-Fusionner

Mais que se passe-t-il si les changements de Sally chevauchent les changements d'Harry ? Que se passe-t-il alors ? Cette situation est appelée un conflit et habituellement, ce n'est pas vraiment un problème. Quand Harry demande à son client de fusionner les derniers changements du dépôt vers sa copie de travail, sa copie du fichier A est marquée d'une façon ou d'une autre comme étant dans un état de conflit : il sera capable de voir les deux jeux de changements en conflit et choisira manuellement entre eux. Notez que le logiciel ne peut pas résoudre automatiquement les conflits ; seuls les êtres humains sont capables de comprendre et de faire les choix intelligents nécessaires. Une fois qu'Harry a manuellement résolu les changements se chevauchant (peut-être en discutant du conflit avec Sally !), il peut sans risque sauvegarder le fichier fusionné sur le dépôt.

Le modèle copier-modifier-fusionner peut sembler un peu chaotique, mais en pratique, il fonctionne de manière extrêmement fluide. Les utilisateurs peuvent travailler en parallèle, n'ayant jamais à s'attendre. Quand ils travaillent sur les mêmes fichiers, il s'avère que la plupart de leurs changements simultanés ne se chevauchent pas du tout ; les conflits sont peu fréquents. Et le temps que cela prend pour résoudre des conflits est moindre que le temps perdu par un système de verrouillage.

À la fin, tout cela se réduit à un facteur critique : la communication entre les utilisateurs. Quand les utilisateurs communiquent mal, les conflits tant syntaxiques que sémantiques augmentent. Aucun système ne peut forcer les utilisateurs à communiquer parfaitement et aucun système ne peut détecter les conflits sémantiques. Ainsi il n'y a aucune raison d'être apaisé par une fausse promesse qu'un système de verrouillage empêchera d'une façon ou d'une autre des conflits ; en pratique, le verrouillage semble inhiber la productivité plus qu'autre chose.

Il y a une situation commune où le modèle verrouiller-modifier-déverrouiller s'en sort mieux et c'est quand vous avez des fichiers qui ne sont pas fusionnables. Par exemple, si votre dépôt contient quelques images graphiques et deux personnes modifient une image en même temps, il n'y a aucun moyen de fusionner ces changements. Soit Harry, soit Sally perdra ses changements.

Que fait Subversion ?

Subversion utilise la solution copier-modifier-fusionner par défaut et dans des nombreux cas c'est tout ce dont vous aurez jamais besoin. Cependant, à partir de la version 1.2, Subversion supporte aussi le verrouillage de fichier, si vous avez des fichiers non-fusionnables, ou si vous êtes simplement forcés à une politique de verrouillage par le management, Subversion fournira encore les fonctionnalités dont vous avez besoin.