Que puis-je faire pour éviter les conflits d'écriture-écriture sur un site Web de style wiki?

Question

Sur un site Web de style wiki, que puis-je faire pour empêcher ou atténuer les conflits d'écriture-écriture tout en permettant au site de fonctionner rapidement et en gardant le site facile à utiliser?

Le problème que je prévois est le suivant:

1. l'utilisateur A commence à modifier un fichier
2. l'utilisateur B commence à modifier le fichier
3. l'utilisateur A termine l'édition du fichier
4. L'utilisateur B termine l'édition du fichier et écrase par inadvertance toutes les modifications de l'utilisateur A

Voici quelques approches que j'ai trouvées:

• Avoir une sorte de système de contrôle / enregistrement / verrouillage (bien que je ne sache pas comment empêcher les personnes de garder un fichier archivé "trop ??longtemps", et je ne veux pas que les utilisateurs soient frustrés en n'étant pas autorisé à effectuer une modification)
• disposer d'un système diff qui affiche les autres modifications apportées lorsqu'un utilisateur valide ses modifications. et permet une sorte de fusion (mais je crains que cela sera difficile à créer et rendrait le site "trop ??difficile" à utiliser)
• Avertissez les utilisateurs des modifications simultanées lorsqu'ils effectuent leurs modifications (une sorte d'AJAX?)

Y a-t-il d'autres solutions? Des exemples de sites qui implémentent ce puits?

Answer 1

Mémorisez le numéro de version (ou ID) de la dernière modification. Lisez ensuite l'entrée avant de l'écrire et comparez si cette version est toujours la même.

En cas de conflit, informez l'utilisateur qui essayait d'écrire l'entrée modifiée entre-temps. Soutenez-le avec un diff.

La plupart des wikis le font de cette façon. MediaWiki , Usemod , etc .

Answer 2

Fusion à trois voies: La première chose à souligner est que la plupart des modifications simultanées, en particulier sur des documents plus longs, concernent différentes sections du texte. Par conséquent, en notant quelle révision les utilisateurs A et B ont acquise, nous pouvons effectuer une fusion à trois voies, comme détaillé par Bill Ritcher de Guiffy Software . Une fusion à trois voies peut identifier où les modifications ont été apportées à partir de l'original et, à moins qu'elles ne se contredisent, elle peut fusionner les deux modifications dans un nouvel article. Idéalement, à ce stade, effectuez la fusion et montrez le nouveau document à l'utilisateur B afin qu'il puisse choisir de le réviser.

Résolution de la collision: Cela vous laisse avec le scénario lorsque les deux éditeurs ont édité la même section. Dans ce cas, fusionnez tout le reste et proposez le texte des trois versions à l'utilisateur B - c'est-à-dire, incluez l'original - avec la version de l'utilisateur A dans la zone de texte ou celle de l'utilisateur B. Ce choix dépend de si vous pensez que le choix par défaut devrait être d'accepter les dernières (l'utilisateur clique simplement sur Enregistrer pour conserver sa version) ou de forcer l'éditeur à modifier deux fois pour obtenir ses modifications (il doit ré-appliquer ses modifications à l'éditeur A version de la section).

Ce type de fusion à trois voies évite les verrouillages, qui sont très difficiles à gérer sur le Web (combien de temps les laissez-vous verrouiller?), et le scénario aggravant «vous voudrez peut-être revoir» , qui ne fonctionne que pour les réponses de type forum. Il conserve également le style post-réponse du Web.

Si vous souhaitez ajuster légèrement la valeur, fusionnez la version de l'utilisateur A de manière dynamique dans la version de l'utilisateur B lors de la modification , puis notifiez-la. Maintenant, ce serait impressionnant.

Answer 3

Dans Mediawiki, le serveur accepte la première modification, puis lorsque la deuxième modification est enregistrée, une page de conflits s'affiche, puis la deuxième personne fusionne les deux modifications. Voir Wikipedia: Aide: Modifier les conflits

.

Answer 4

L'utilisation d'un mécanisme de verrouillage sera probablement la plus simple à mettre en œuvre. Chaque article peut être associé à un champ de verrouillage et à une heure de verrouillage. Si le temps de verrouillage dépasse une valeur définie, vous considérerez que le verrouillage est invalide et le supprime lorsque vous extrayez l'article à modifier. Vous pouvez également suivre les verrous ouverts et les supprimer à la fermeture de la session. Vous devez également implémenter un contrôle de concurrence dans la base de données (des horodatages générés automatiquement, par exemple) afin de vous assurer que vous archivez une mise à jour de la version que vous avez extraite, juste au cas où deux personnes pourraient éditer le fichier. article en même temps. Seul celui dont la version est correcte pourra archiver une édition.

Vous pourrez peut-être également trouver un moteur de différence que vous pourriez simplement utiliser pour construire des différences, bien que leur affichage dans un éditeur de wiki puisse être problématique: afficher les différences est probablement plus difficile que de construire le diff. Vous comptez sur le système de gestion des versions pour détecter le moment où vous devez rejeter une modification et effectuer un diff.

Answer 5

Dans Gmail, si nous écrivons une réponse à un courrier et que quelqu'un d'autre envoie une réponse alors que nous sommes en train de le taper, une fenêtre contextuelle apparaît pour indiquer qu'il existe une nouvelle mise à jour et la mise à jour elle-même apparaît sous la forme d'un autre message sans rechargement de page. . Cette approche conviendrait à vos besoins et si vous pouvez utiliser Ajax pour afficher le message exact avec un lien vers le diff de ce qui vient d'être mis à jour alors que l'utilisateur B est toujours en train de taper son entrée, ce serait génial.

Answer 6

Comme Ravi (et d’autres) l’ont dit, vous pouvez utiliser une approche AJAX et informer l’utilisateur quand un autre changement est en cours. Lorsqu’une modification est soumise, indiquez simplement les différences textuelles et laissez le deuxième utilisateur déterminer comment fusionner les deux versions.

Toutefois, j'aimerais ajouter quelque chose de nouveau que vous pouvez essayer en plus: ouvrir une boîte de dialogue de discussion entre les éditeurs pendant qu'ils effectuent leurs modifications. Vous pouvez utiliser, par exemple, Gabbly , par exemple, des fonctions intégrées.
& nbsp;
& nbsp;
La meilleure solution de conflit est le dialogue direct, dis-je.

Answer 7

Votre problème (mise à jour perdue) est mieux résolu en utilisant le contrôle optimiste de la concurrence .

Une implémentation consiste à ajouter une colonne version dans chaque entité modifiable du système. Lors de la modification par l'utilisateur, vous chargez la ligne et affichez le formulaire html sur l'utilisateur. Un champ masqué donne la version, disons 3 . La requête de mise à jour doit ressembler à quelque chose comme:

update articles set ..., version=4 where id=14 and version=3;

Si le nombre de lignes renvoyées est 0, quelqu'un a déjà mis à jour l'article 14. Il vous suffit ensuite de savoir comment gérer la situation. Quelques solutions communes:

1. le dernier commit gagne
2. premier commit gagne
3. fusionner les mises à jour en conflit
4. laisser l'utilisateur décider

Au lieu d'une version incrémentante int / long, vous pouvez utiliser un horodatage , mais cela n'est pas suggéré car:

  

La récupération de l'heure actuelle de la machine virtuelle Java n'est pas nécessairement sûre dans un environnement en cluster, où les nœuds peuvent ne pas être synchronisés.

(citation de persistance Java avec Hibernate )

Quelques informations supplémentaires sur la documentation d'hibernate .

Answer 8

Dans mon bureau, nous avons pour règle que toutes les tables de données contiennent 4 champs:

• CrééPar
• CreatedDate
• LastUpdateBy
• LastUpdateDate

De cette manière, il existe une piste de vérification permettant de déterminer qui a fait quoi dans les enregistrements, du moins récemment.

Mais surtout, il devient assez facile de comparer la LastUpdateDate de l'enregistrement en cours ou modifié à l'écran (vous devez le stocker sur la page, dans un cookie, peu importe, avec la valeur de la base de données. Si les valeurs ne correspond pas, vous pouvez décider quoi faire à partir de là.