jeanlaurent.getBlog()

J’ai subit le mode lock-modify-unlock des outils de gestion de configuration pendant des années gràce à StarTeam, Surround SCM (brièvement c’est tout ce qu’il méritait de toute façon) et plus récemment l’incomparable mastodonte ClearCase.
Le mode “copy-modify-merge” est de loin, à mes yeux, la meilleure solution; voici quelques arguments :

1. Qui dit verrou (lock) dit hiérarchie de “droits de cassage” du verrou, ce qui implique la mise en place permanente sur le projet d’un gugus qui a les super droits de cassage de verrou. Si on systématises les droits (ie On assigne le droit de cassage de verrou à tout le monde… le verrou est vidé de son sens). Et y’a rien de plus pénible, que de justifier auprès du grand guru du cassage de verrou que machin est parti en week-end et qu’il a oublié0 de déverouiller.
2. Le lock / unlock est une étape de plus dans le processus de gestion de configuration.
   • Lorsque je checkout faut que je réfléchisse à savoir si je prends le lock ou pas.
   • Lorsque je commit faut que je réfléchisse à savoir si je rends le lock et pourquoi.
3. Parfois tu es dans la situation ou tu as locké un bon paquet de répertoires (justifié : lors d’un refactoring important par exemple) et tu es un peu obligé de de-locker une partie des répertoires et de garder le lock sur le reste. Même si tu n’as pas tout à fait terminé, il faut parfois “rendre la main”. Là, c’est parti pour être un cauchemar pour retrouver ce qui a été modifié…
4. En jouant la carte du lock/unlock on renforce l’idée de la peur du merge. Le merge est pas difficile !! Il suffit de se l’être farci une paire de fois pour le comprendre. Surtout qu’avec des outils comme subversion tout ce qui peut être mergé de façon facile est fait automatiquement, y’a que les “embrouilles” qu’il ne fait pas. Cela dit, lorsqu’il y a conflit, je préfére sortir un outil sur mesure et faire ça manuellement que de laisser faire la “magie”.
5. Mais les raisons ci dessus sont des peccadilles, la raison principale c’est que le commit doit être systèmatisé. Lorsque on prone le lock, on prone la protection, le renfermement sur soi du développeur. Idéalement les commit devraient être très rapides, ne jamais conserver des fichiers modifiés plus de quelques heures. On renforce l’attitude qui consiste à conserver ses fichiers 3 mois sur son disque dur. Là, le type qui a cette attitude, et il y en a encore un bon paquet même en 2006, il le fera qu’une seule fois. Passé le merge monumental pour ne pas avoir commité plus tôt, il va commiter bien plus vite. Mieux vaut commiter quelques erreurs tous les jours que toutes les erreurs d’un coup.

Faire un projet en mode lock, c’est un peu comme faire des specs exhaustives pendant 3 mois, ca parait une bonne idée sur le papier; en pratique c’est n’importe quoi. C’est un peu extrême, mais j’assume

Référence :

• Versioning Models