SVNBOOK Chap1 Versioning Models
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Penguin | Traduction | Terminé | |
| Flo | Relecture | ||
| SVF | 2ème Relecture | Fait | |
| HST | mise à jour version 1.5 | Fait | |
| Validation |
Sommaire |
Titre
Versioning Models
Modèles de versionnement
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?
--Sub Versif 26 février 2009 à 11:41 (CET) : "tout d'abord" et "ensuite" passent mieux en effet.
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.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, 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, 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...
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, 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
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 they need 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 relativement 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, qui est encore en train d'attendre pour éditer le fichier, est bloquée. Puis Harry part en vacances. Sally doit alors aller trouver un administrateur pour libérer le verrou de Harry. La situation finit par générer 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âts, en supposant que les changements soient correctement fusionnés. Dans cette situation, il n'est pas nécessaire de les forcer à éditer le fichier chacun à 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 et édite le fichier B simultanément. Que se passe-t-il si A et B dépendent l'un de l'autre et que les changements faits à chacun sont incompatibles d'un point de vue sémantique ? A et B ne fonctionnent soudainement plus ensemble. Le système de verrouillage a été incapable d'empêcher ce problème, bien qu'il ait d'une certaine manière instillé un faux sentiment de sécurité. Il est facile pour Harry et Sally d'imaginer qu'en verrouillant les fichiers, chacun commence une tâche isolée et sans danger, et donc ils ne ne prennent pas la peine de discuter à l'avance de leurs modifications incompatibles. Verrouiller devient souvent un substitut à une réelle communication.
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 versions utilisent le modèle copier-modifier-fusionner comme alternative au verrouillage. Dans ce modèle, chaque utilisateur contacte le dépôt du projet via son client et crée une copie de travail personnelle, une sorte de version locale des fichiers et des répertoires du dépôt. Les utilisateurs peuvent alors travailler simultanément et indépendamment les uns des autres, et modifier leurs copies privées. Pour finir, les copies privées sont fusionnées au sein d'une nouvelle version finale. Le système de gestion de versions fournit de l'aide afin de réaliser cette fusion, mais au final la responsabilité de s'assurer que tout se passe bien incombe à un être humain.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, 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; 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 son fichier A est périmé. En d'autres termes, le fichier A dans le dépôt a changé d'une façon ou d'une autre 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)" illustrent ce processus.
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 marqué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 qu'un logiciel ne peut pas résoudre automatiquement les conflits ; seuls les humains sont capables de comprendre et de 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.
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 devoir 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.
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 les conflits sémantiques. Il n'y a donc aucun intérêt à se laisser endormir par un faux sentiment de sécurité selon lequel un système de verrouillage permettrait d'éviter les conflits ; en pratique, le verrouillage semble limiter la productivité plus qu'aucun autre facteur.
Paragraphe 11
When Locking is Necessary
While the lock-modify-unlock model is considered generally harmful to collaboration, sometimes 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 for 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. We discuss this feature 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 y a quand même des cas où le verrouillage est approprié.
Le modèle copier-modifier-fusionner est basé sur l'hypothèse 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, tels que 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 ne modifient le fichier qu'à tour de rôle. Sans accès sérialisé, quelqu'un finirait par perdre du temps sur des modifications qui seraient finalement perdues.
Bien que Subversion soit avant tout un système copier-modifier-fusionner, il reconnaît toutefois la nécessité du verrouillage pour certains fichiers et fournit donc un mécanisme pour cela. Cette fonctionnalité sera traitée plus tard dans ce livre, dans la section appelée "Verrouillage".
