SVNBOOK Chap1 Versioning Models
Un article de Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Penguin | Traduction | Terminé | |
| Flo | Relecture | ||
| Validation |
Sommaire |
[modifier] Titre
Versioning Models
Modèles de versionnement
[modifier] Paragraphe 1
The core mission of a version control system is to enable collaborative editing and sharing of data. But different systems use different strategies to achieve this. It's important to understand these different strategies for a couple of reasons. First, it will help you compare and contrast existing version control systems, in case you encounter other systems similar to Subversion. Beyond that, it will also help you make more effective use of Subversion, since Subversion itself supports a couple of different ways of working.
La mission essentielle d'un système de gestion de versions est de permettre l'édition collaborative et le partage de données. Mais il existe différentes stratégies pour réaliser cela. Comprendre ces différentes stratégies est important pour plusieurs raisons. Tout d'abord, cela vous aidera à comparer et différencier les différents systèmes de gestion de versions existants, au cas où vous rencontriez d'autres systèmes similaires à Subversion. Ensuite, cela vous aidera également à utiliser plus efficacement Subversion, puisque Subversion lui-même autorise différentes façons de travailler.
--Flo 17 août 2008 à 06:04 (CEST):
J'ai supprimé "au delà de cela", qui était lourd en français. Tout d'abord... ensuite me paraît plus juste, et ne trahit pas l'esprit. Cela me paraît moins "militaire" que "premièrement", "deuxièmement". Votre avis?
[modifier] Paragraphe 2
The Problem of File-Sharing
All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.Le Problème du Partage de Fichiers
Tous les systèmes de gestion de versions doivent résoudre le même problème fondamental : comment le système va-t-il permettre aux utilisateurs de partager l'information, mais les empêcher de se marcher mutuellement sur les pieds par accident ? Il est vraiment trop facile pour les utilisateurs d'écraser malencontreusement les changements effectués par d'autres dans le dépôt.[modifier] Paragraphe 3
Consider the scenario shown in Figure 1.2, “The problem to avoid”. Suppose we have two co-workers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, then it's possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry's version of the file won't be lost forever (because the system remembers every change), any changes Harry made won't be present in Sally's newer version of the file, because she never saw Harry's changes to begin with. Harry's work is still effectively lost—or at least missing from the latest version of the file—and probably by accident. This is definitely a situation we want to avoid!
Observons le scénario décrit à la figure 1.2, "Le problème à éviter". Supposons que nous ayons deux collaborateurs, Harry et Sally. Ils décident tous les deux d'éditer le même fichier dans le dépôt au même moment. Si Harry sauvegarde ses modifications dans le dépôt en premier, alors il est possible que (quelques instants plus tard) Sally les écrase avec sa propre version du fichier. Bien que la version de Harry ne soit pas perdue pour toujours (car le système se souvient de tous les changements), aucune des modifications effectuées par Harry ne sera présente dans la nouvelle version du fichier de Sally, car elle n'aura jamais vu les changements réalisés par Harry. Le travail de Harry est perdu dans les faits, ou du moins perdu dans la version finale du fichier, et ceci probablement par accident. Il s'agit précisément d'une situation que nous voulons à tout prix éviter!
--Flo 17 août 2008 à 06:16 (CEST):
Je trouve que "la nouvelle version du fichier de Sally" ne passe pas en Français (c'est lourd et pas très clair). Je pense qu'on s'en sortirait peut-être mieux avec une périphrase, mais comme je n'ai rien trouvé de vraiment satisfaisant, je n'ai pas modifié pour le moment...
[modifier] Paragraphe 4
The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address the problem of many authors clobbering each other's work. In this model, the repository allows only one person to change a file at a time. This exclusivity policy is managed using locks. Harry must “lock” a file before he can begin making changes to it. If Harry has locked a file, then Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release his lock. After Harry unlocks the file, Sally can take her turn by locking and editing the file. Figure 1.3, “The lock-modify-unlock solution” demonstrates this simple solution.La Solution "Verrouiller-Modifier-Libérer"
Beaucoup de systèmes de gestion de versions utilisent le modèle verrouiller-modifier-libérer pour résoudre le problème de plusieurs auteurs annihilant le travail des autres. Dans ce modèle, le dépôt ne permet qu'à une seule personne de modifier un fichier à un instant donné. Cette politique exclusive est gérée grâce à des verrous ("lock" en anglais). Harry doit "verrouiller" un fichier avant de commencer à le modifier. Si Harry a verrouillé un fichier, alors Sally ne pourra pas le verrouiller, et ne pourra donc faire aucun changement dessus. Tout ce qu'elle pourra faire sera de lire le fichier, et attendre que Harry ait fini ses changements et libéré le verrou. Après que Harry ait libéré le fichier, Sally peut le prendre à son tour en le verrouillant et en éditant le fichier. La figure 1.3, "La solution verrouiller-modifier-libérer" montre cette solution simple.--Danarmk 17 septembre 2007 à 13:03 (CEST):
Je me demande si "Libérer" est mieux que "Déverrouiller". Votre avis ?
--Hotshot92 22 novembre 2008 à 14:21 (CET):
Oui, libérer un verrou se lit bien
[modifier] Paragraphe 5
The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users:
- Locking may cause administrative problems. Sometimes Harry will lock a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry's lock. The situation ends up causing a lot of unnecessary delay and wasted time.
- Locking may cause unnecessary serialization. What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don't overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There's no need for them to take turns in this situation.
- Locking may create a false sense of security. Suppose Harry locks and edits file A, while Sally simultaneously locks and edits file B. But what if A and B depend on one another, and the changes made to each are semantically incompatible? Suddenly A and B don't work together anymore. The locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It's easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus not bother discussing their incompatible changes early on. Locking often becomes a substitute for real communication.
Le problème avec le modèle verrouiller-modifier-libérer est qu'il est relativemnt restrictif, et devient souvent un barrage pour les utilisateurs :
- Le verrouillage peut créer des problèmes d'administration. Parfois, Harry va verrouiller un fichier et oublier qu'il l'a fait. Pendant ce temps, Sally est encore en train d'attendre pour éditer le fichier, bloquée. Puis Harry part en vacances. Sally doit alors aller trouver un administrateur pour libérer le verrou de Harry. La situation se résout mais a généré beaucoup de délais inutiles et de temps perdu.
- Le verrouillage peut créer une sérialisation inutile. Que se passe-t-il lorsque Harry veut éditer le début d'un fichier texte et que Sally veut simplement éditer la fin de ce même fichier ? Les changements ne se chevauchent pas du tout. Ils pourraient aisément éditer le fichier simultanément, et il n'y aurait pas beaucoup de dégât, en supposant que les changements soient correctement fusionnés ensemble. Il n'est pas nécessaire pour eux d'attendre leur tour.
- Le verrouillage peut créer un faux sentiment de sécurité. Supposons que Harry verrouille et édite le fichier A, pendant que Sally verrouille simultanément et édite le fichier B. Mais si A et B dépendent l'un de l'autre et que les changements faits à chacun sont incompatibles ? A et B ne fonctionnent soudainement plus ensemble. Le système de verrouillage est incapable de prévenir ce problème, donnant même un faux sentiment de sécurité. Il est facile à Harry et Sally d'imaginer qu'en verrouillant les fichiers, chacun commence une tâche sûre, isolée, et donc ne se préoccupent pas de discuter des incompatibilités créées par leur changement. Verrouiller devient souvent un substitut à une réelle communication.
[modifier] Paragraphe 6
The Copy-Modify-Merge Solution
Subversion, CVS, and many other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy—a local reflection of the repository's files and directories. Users then work simultaneously and independently, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.La Solution Copier-Modifier-Fusionner
Subversion, CVS, et beaucoup d'autres systèmes de gestion de version utilisent le modèle copier-modifier-fusionner comme alternative au verrouillage. Dans ce modèle, chaque utilisateur client contacte le dépôt du projet et crée une copie de travail personnelle, un reflet local des fichiers et des répertoires du dépôt. Les utilisateurs peuvent alors travailler simultanément et indépendamment, modifiant leurs copies privées. Enfin, les copies privées sont fusionnées dans une nouvelle version finale. Le système de gestion de versions aide souvent à réaliser cette fusion, mais la responsabilité finale incombe à un être humain pour que cela se passe correctement.[modifier] Paragraphe 7
Here's an example. Say that Harry and Sally each create working copies of the same project, copied from the repository. They work concurrently, and make changes to the same file A within their copies. Sally saves her changes to the repository first. When Harry attempts to save his changes later, the repository informs him that his file A is out-of-date. In other words, that file A in the repository has somehow changed since he last copied it. So Harry asks his client to merge any new changes from the repository into his working copy of file A. Chances are that Sally's changes don't overlap with his own; so once he has both sets of changes integrated, he saves his working copy back to the repository. Figure 1.4, “The copy-modify-merge solution” and Figure 1.5, “The copy-modify-merge solution (continued)” show this process.
Voici un exemple. Supposons que Harry et Sally aient créé chacun des copies de travail du même projet, copiées à partir du dépôt. Ils travaillent simultanément, et effectuent sur leur copie des modifications du même fichier A. Sally sauvegarde ses changements dans le dépôt en premier. Lorsque Harry essaie par la suite de sauvegarder ses modifications, le dépôt l'informe que le fichier A est périmé. En d'autres termes, que le fichier A dans le dépôt a en partie changé depuis la dernière fois qu'il l'avait copié. Harry demande donc à son client de fusionner tous les changements en provenance du dépôt dans sa copie de travail du fichier A. Il y a des chances que les modifications de Sally ne se chevauchent pas avec les siennes; une fois qu'il a intégré les changements provenant des deux côtés, il sauvegarde sa copie de travail dans le dépôt. La Figure 1.4, "La solution copier-modifier-fusionner" et la Figure 1.5, "La solution copier-modifier-fusionner (suite)" montrent ce processus.
[modifier] Paragraphe 8
But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes—perhaps after a discussion with Sally—he can safely save the merged file back to the repository.
Mais que se passe-t-il si les modifications de Sally se chevauchent avec celles de Harry ? Que fait-on dans ce cas-là ? Cette situation est appelée un conflit, et ce n'est en général pas un gros problème. Lorsque Harry demande à son logiciel client de fusionner les changements les plus récents du dépôt dans sa copie de travail, sa copie du fichier est en quelque sorte signalée comme étant dans un état de conflit: il aura la possibilité de voir les deux ensembles de changements créant un conflit, et de choisir manuellement entre les deux. Notez bien que le logiciel ne peut pas résoudre automatiquement les conflits, seuls les humains sont capables de comprendre et faire les choix intelligents nécessaires. Une fois que Harry a manuellement résolu les modifications se chevauchant, peut-être après une discussion avec Sally, il peut sauvegarder le fichier fusionné en toute sécurité dans le dépôt.
[modifier] Paragraphe 9
The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is usually far less than the time lost by a locking system.
Le modèle copier-modifier-fusionner peut sembler un peu chaotique, mais en pratique, il fonctionne parfaitement sans à-coups. Les utilisateurs peuvent travailler en parallèle, sans jamais s'attendre les uns les autres. Lorsqu'ils travaillent sur les mêmes fichiers, il se trouve que la plupart des changements réalisés en parallèle ne se chevauchent pas du tout; les conflits sont rares. Et le temps nécessaire à résoudre les conflits est en général bien inférieur au temps perdu par un système de verrouillage.
[modifier] Paragraphe 10
In the end, it all comes down to one critical factor: user communication. When users communicate poorly, both syntactic and semantic conflicts increase. No system can force users to communicate perfectly, and no system can detect semantic conflicts. So there's no point in being lulled into a false sense of security that a locking system will somehow prevent conflicts; in practice, locking seems to inhibit productivity more than anything else.
Au final, tout revient à un facteur critique: la communication entre les utilisateurs. Lorsque les utilisateurs communiquent mal, les conflits syntaxiques et sémantiques augmentent. Aucun système ne peut forcer les utilisateurs à communiquer parfaitement, et aucun système ne peut détecter des conflits sémantiques. Il n'y a donc aucun intérêt à se laisser endormir dans le faux sentiment de sécurité qu'un système de verrouillage peut prévenir les conflits; en pratique, le verrouillage semble limiter la productivité plus qu'aucun autre facteur.
[modifier] Paragraphe 11
When Locking is Necessary
While the lock-modify-unlock model is considered generally harmful to collaboration, there are still times when locking is appropriate.
The copy-modify-merge model is based on the assumption that files are contextually mergeable: that is, that the majority of the files in the repository are line-based text files (such as program source code). But for files with binary formats, such as artwork or sound, it's often impossible to merge conflicting changes. In these situations, it really is necessary to users to take strict turns when changing the file. Without serialized access, somebody ends up wasting time on changes that are ultimately discarded.
While Subversion is still primarily a copy-modify-merge system, it still recognizes the need to lock an occasional file and thus provide mechanisms for this. This feature is discussed later in this book, in the section called “Locking”.Lorsque Verrouiller est Nécessaire
Même si le modèle verrouiller-modifier-libérer est en général considéré comme pénalisant pour la collaboration, il existe toutefois des cas où le verrouillage est approprié.
Le modèle copier-modifier-fusionner se base sur la supposition que les fichiers sont contextuellement fusionnables: c'est-à-dire que la majorité des fichiers d'un dépôt sont des fichiers textes (comme le code source d'un programme). Mais pour les fichiers binaires, comme des images ou du son, il est souvent impossible de fusionner les modifications ayant créé un conflit. Dans ces cas-là, il est réellement nécessaire que les utilisateurs soient rigoureux lorsqu'ils font des changements. Sans accès sérialisé, quelqu'un finira par perdre son temps dans des modifications qui seront finalement abandonnées.
Bien que Subversion soit avant tout un système copier-modifier-fusionner, il reconnaît toutefois la nécessité du verrouillage sur certains fichiers bien particuliers et fournit donc un mécanisme pour cela. Cette fonctionnalité sera traitée plus tard dans ce livre, dans la section appelée "Verrouillage".
