PagesConservées

MeatballWiki | RecentChanges | Random Page | Indices | Categories

Cette page a démarré sur KeptPages

Motivation

Plusieurs wikis ont trouvé utile de conserver une HistoriqueVersion de chaque page wiki. Ces plus vieilles versions sont particulièrement utiles pour corriger les erreurs destructives ou le vandalisme modeste (cf. ModificationRéversible). Quelques wikis conservent toutes les modifications (HistoriqueComplète), alors que d'autres n'en conservent qu'une unique copie ancienne (souvent la version précédente de l'auteur précédent). Chaque forme de versioning a ses avantages et inconvénients. Par exemple, une historique permanente signifie que le vandalisme peut toujours être remis en arrière, mais quelques personnes soucieuses de leurs erreurs devenant une section permanente d'une historique de page, contrariant le PardonnerEtOublier. D'un autre côté, un système qui ne conserve seulement la trace que d'un nombre fixe de copies est facilement battu par la production du nombre fixé plus un des éditions fraîches -- soit par un attaquant, ou même par l'action de beaucoup d'auteurs innoccents.

L'idée originale des PagesConservées était de trouver un terrain d'entente entre conserver toutes les versions et le fait de conserver un petit nombre fixé de versions

Solution

Nous avons choisi de tout versionner, mais de ne garder seulement que les révisions sur un laps de temps limité, disons une semaine ou un mois. Ce qui veut dire, détruire toutes les révisions plus vieilles que l'intervalle de temps. L'intervalle de temps dépendra naturellement de la quantié de trafic sur le site, plus le site est lent, plus grand est l'intervalle.

Ce schéma n'est néanmoins pas suffisant, parce qu'un attaquant peut détruire une page qui n'a pas été touchée depuis plusieurs mois en l'éditant simplement. Après tout, toutes ses versions précédentes ont été automatiquement effacées, vous laissant avec seulement la dernière version, la version vandalisée.

Par conséquent, nous l'avons un peu tordu : un laps de temps sur les révisions pas quand elles sont créées mais quand elles sont remplacées. Ainsi, la version en cours de la page n'est pas dans l'historique de révision, mais quand je produis une modification, la version en cours se fait ensuite chronodoté et entre dans l'historique. Alors la nouvelle édition devient la version en cours. Voir ExemplePagesConservées? (KeptPagesExample).

De la même manière et plus simplement, vous conserverz toutes les révisions précédentes durant l'intervalle, plus une de plus.

Fondamentalement, au lieu de conserver un nombre fixe de sauvegardes, vous conservez un temps fixé de sauvegardes. (Cela sera probablement utile de conserver une version de sauvegarde de chaque page pour des comparaisons dans un avenir lointain.)

De cette maniière, parce que vous pouvez simplement tout conserver, vous vous protégez contre toute forme d'attaque de vandale, à ce stade vous avez aussi le PardonnerEtOublier des erreurs. En outre, si un vandale veut détruire une veille page, la vieille page sera encore là pour une semaine. Ceci réduit la PerceptionDeVulnérabilité? et est un exemple de DifférerAction.

Voir aussi EffacementPage et RemplacementFichier? pour une technologie inspirée des PagesConservées.

Pour une explication différente de la même chose, voir la section Pages Conservées sur le manuel Oddmuse. [1]. Un résumé est aussi déposé sur Community Wiki [2]

DossierTechnologieWiki

Avantages.

Un effet positif est que ces types de PagesConservées devrait encourager le remaniement en minimisant l'impact des erreurs. Les personnes pourraient se sentir plus libres de retirer le contenu de la version en cours, parce que les anciennes versions resteront disponibles durant un laps de temps décent.

Cette idée permet à n'importe quel nombre de personnes de participer dans l'édition d'une page, sans que la contribution de quiconque ne soit perdue. D'un autre côté, d'autres versions conservées du contenu vieux/gênant expirera raisonnablement tôt. Plus de copies sont sauvegardées pour les pages les plus populaires (éditées par plus de gens). Les pages qui n'ont pas été éditées récemment auront seulement la version en cours.

Bien que l'espace disque ne soit pas un problème majeur, par nos estimations les PagesConservées devraient requérir beaucoup moins d'espace de stockage que le système actuel de multi-copie (qui a potentiellement beaucoup de copies pour des pages qui n'ont pas été éditées depuis des mois). Même dans les pires cas (comme une page BacASable ou le journal en ligne d'une personne) disposeront d'un nombre raisonnable de copies -- cela conservera une page pour chaque auteur distinct dans les derniers N jours (où N est l'intervalle d'expiration). Comparez cela avec une HistoriqueComplète contenant un BacASable de centaines d'éditions (comme celui de Wiki:WikiWikiSandbox).

Inconvénients.

Soin Supplémentaire requis.

Les PagesConservées font qu'il est plus important de ne pas produire d'éditions molles (ce qui est probablement une bonne chose). Maintenant, la totalité de l'historique d'une page est conservée durant deux semaines, y compris chacune de vos petites pincées. Il est possible désormais de décrocher pour sécher sur des charges forgées fondées sur du texte mal écrit, du texte qui n'expliquait pas proprement votre intention, ainsi vous l'avez modifié. Par conséquent, parce que nous pratiquons SupposerBonneFoi, la meilleure chose à faire en tant que lecteur est de supposer que la version actuelle de la page reflète proprement les attitudes de toutes les parties impliquées. L'historique du site n'est pas vraiment pas si importante parce que les visiteurs ne s'en soucient pas.

Deuxièment, PagesConservées protège aussi un travail d'agresseur. Par conséquent, l'agresseur peut simplement aussi facilement restaurer les contenus abimés de la page en tant que défénseur. Ceci devient problématique durant les guerres enflammées (-- mais celles ci requièrent une SolutionCommunauté, pas une SolutionTechnologie pour être résolues, voir RésolutionConflit?) et quand les vandales sont en quête d'attention.

Dans le dernier cas, il est normalement mieux de rire avec les vandales et puis par la suite réparer le site (vandalisme et mignardise). Prendre les choses trop sérieusement invite après tout au vandalisme, peut être avec quelque justification. Comparez les trolls SlashDot sur SlashDot vs. KuroShin pour voir ceci en action (voir TrollTalk). RobMalda est dur avec les trolls, invitant aux guerres du feu, tandis que RustyFoster décroche sur le TrollTalk et a un sens de l'humour. Pas que les trolls soient de méchants vandales, mais l'approche est la même.

Espace Disque.

Je pensais au problème de l'historique version consommant une quantité excessive d'espace-disque. Alors que je suis d'accord sur le fait que maintenir chaque version est un bon idéal, une idée est de comprimer les modifications après un usage disque (ou un compteur de version) une fois le seuill excédé. Ce qui veut dire, démarrer à partir de la seconde modification la plus ancienne, pour chaque ensemble consécutif d'éditions par le même auteur, remplacer le jeu complet par la dernière édition de cet auteur. Répéter jusqu'à ce que les pages conservées tombent sous le seuil ou vous pouvez faire fonctionner toute l'historique complète. Alors si vous êtes intransigeant sur le sujet d'extraire les versions sous l'historique, vous pouvez commencer à laisser tomber les versions les plus anciennes jusqu'à ce que vous soyez sous le seuil. -- SunirShah

Un bon système de contrôle de version ne devrait stocker que les différences, et je m'attendrais à ce que les différences entre des éditions successives par le même auteurs soient petites. Ou même entre différents auteurs. Cad pour cette édition que je fais, le stockage pourrait augmenter de seulement un paragraphe unique. Mon disque dur actuel est de 40 Gigabytes. Cela prendre beaucoup d'éditions de 1 paragraphe pour remplir tout cela. -- DaveHarris

: L'espace disque n'est vraiment pas un problème mais il y a encore ces compromis à faire. Usemod.com est actuellement (Décembre 2000) sur un serveur partagé (ce qui est bien meilleur marché qu'un serveur dédié, et beaucoup moins de souci qu'essayer de faire tourner un serveur 24X7 à la maison). J'ai payé pour 75 MB de stockage, et le stockage supplémentaire est de $5/20MB/mois. (Ce n'est pas le fournisseur le moins cher, mais ils ont un bon enregitrement de personnes donnant véritablement la totalité de leurs allotements plutôt que de fermer des comptes qui tournent à plein régime).

: Parce que l'espace disque est le mien, mais que je partage la CPU avec beaucoup d'autres comptes, j'ai décidé de mnimiser l'usage CPU au coût d'espace disque supplémentaire. Chaque édition stocke une copie complète de la précédente version dans la base de données des pages conservées. Alors qu'il est possible de reconstruire les versions à partir d'une chaîne de diffs, c'est plein plus intensif en CPU. Je peux acheter plus facilement de l'espace disque, mais plus de CPU obligera à un serveur dédié. (Environ $250/mois en plus.)

: MeatballWiki a actuellement environ 50 megabytes d'espace libre pour grandir. Ceci est suffisant pour 1000 éditions de 50k pages dans la date d'expiration (actuellement une valeur par défaut de 14 jours). En comparaison, MeatballWiki a eu envrion 5000 éditions durant les 6 derniers mois, et la vaste majorité des pages sont bien en dessous de 50k. (la moyenne de stockage par page était environ de 10K avant la conversion, y compris le texte de la page, jusqu'à deux copies d'édition (majeure+auteur), et jusqu'à trois diffs stockées. J'ai la volonté d'acheter plus d'espace s'il est bien utilisé. --CliffordAdams

Avez-vous étudié de stocker les deltas pour minimiser l'espace, et puis paresseusement cacher les versions des pages pour minimiser le temps ? Ceci vous permettrait de ne stocker seulement que les pages pleines pour les versions qui étaient véritablement en train d'être utilisées. -- DaveHarris

Avez-vous même imaginé de stoker les deltas réinitialisés, ala [RCS] ? De cette manière vous conservez la CPU en stockant une copie complète de la version la plus actuelle, qui est probablement celle la plus accédée, mais vous réduisez l'usage de l'espace pour les versions historiques, parce que vous les stockez comme deltas à partir de la version la plus récente. --anon.

La plupart des grands wikis implémentent maintenant l'excellente proposition de Sunir pour le versioning.

Je peux voir un autre problème mineur avec ça :

Perte de l'Auteur Original

Peut-être que la toute première version d'une page devrait être conservée, sans regard au passage du temps. Quand nous perdons la toute première incarnation d'une page, non seulement nous perdons la chance de voir comment elle a été modifée (parfois c'est pour une alouette, mais ce pourrait être utile sur beaucoup de page pour pister une idée changeante), mais nous perdons aussi l'identité du créateur. Quand nous ne savons pas qui est à l'origine de la page, nous ne savons pas nécessairement qui contacter pour plus d'information, ou qui citer dans un rapport. J'écris à cette heure un rapport sur les wikis et malheureusement, la plupart des informations postées sur différents wikis traitant des concepts wikis et son histoire sont tous arrivés il y a des mois ou des années, leurs versions originales sont désormais expirées, et me laisse citer des pages anonymement. En conservant la pag originale, nous ne résolvons pas tous ces cas, mais ce peut être une pièce d'histoire qu'une communauté wiki peut être enthousiaste à gérer.

-- Josh Hoey, 2003-05-10

Vrai, mais je pense que si vous vouliez conserver l'information sur la paternité de l'oeuvre, alors il serait tout aussi important de conserver l'information sur les contributeurs plus tardifs tout comme la page originale de l'auteur. Je pense que ce peut être valable en fait. Voir CréditPaternitéOeuvre?.

-- BayleShanks

: L'[Internet Archive] est une solution possible. Il semble que le désir anticipé articulé au-dessus n'est pas parfait pour le versioning, mais plutôt la capacité d'apercevoir des moments occasionnels dans le passé d'un site, que ce soit pour les premières versions ou des versions occasionnelles intermédiaires. Voir par exemple, ce que notre leader sans crainte était à la hauteur en [Décembre 2000]. Effacer une larme à la vue de ce logo familier ! ;-) Ou témoigner [ZenWindow] (c.f. SiteSacré) à sa pleine heure de gloire en 1995. -- anon.

Vous pouvez remarquer une perte occasionnelle inattendue des versions sur MeatballWiki. Le script a accès à une quantité limitée de RAM, et ainsi il peut prématurément faire expirer des vieilles versions s'il ne peut pas manipuler la totalité de l'historique de version. Il est cru que OddMuse n'a pas ce problème, parce qu'il retient les versions individuelles dans des fichiers séparés.

Un LogAuteur. Afin de supporter OpenMeatballWiki, les PagesConservées devraient aussi maintenant stocker la liste des contributeurs, mais seulement une liste des IPs/domaines/NomUtilisateurs (pas le timbredaté ni le résumé ni la séquence) de qui a édité la page tout comme n'importe lesquels des liens produits sur la page qui sont des CategoryHomePages. Points en plus pour corréler les CategoryHomePages à partir de la diff avec les IPs/domaines (dans une liste séparée). Du point de vue InterfaceUtilisateur, vous ne pouvez seulement vouloir lister une ligne Contributeurs : dans l'historique. Les IPs/domaines peuvent être listés collectivement comme 'N anonymes' où N est le nombre d'auteurs anonymes. Ce texte serait un lien qui générerait la liste "hypothétique" des corrélations entre les IPs/domaines et CategoryHomePages. -- SunirShah

: l'historique permanente veut dire que le vandalisme peut presque toujours être réinitialisé, mais que quelques personnes sont concernées sur leurs fautes devenant une part permanente d'une historique de page, contrecarrant le PardonnerEtOublier.

On peut également mettre en place des admins site étant capables d'effacer les révisions d'historique individuelles (pour attaquer le WikiSpam). Si votre admin est sympathique, je suis sûr que vous pourriez imaginer le faire pour épargner la gêne d'un utilisateur sur quelque chose qu'il aurait écrit de particulièrement idiot. Bien sûr, vous feriez mieux d'espérer d'avoir un bon RoiDieu. Par dessus tout, je pense les avantages d'une HistoriqueComplète dépassent les inconvénients. A e stade, l'équivalent wiki de Wiki:GhostOfUsenetPostingsPast pourrait être mauvais, mais rendre les versions historiques NonIndexée? NotIndexed et vous pouvez minimiser ses effets pour vos utilisateurs. (Peut-être que chaque wiki devrait avoir un signe sur la page d'édition : ThinkBeforeHittingSave?.) -- EarleMartin

Je suis très frustré ici des problèmes de mise en oeuvre des PagesConservées. J'ai perdu des heures de travail sur ProblemSolving (traduire en RésolutionDeProblème?) et BrainStorming du fait d'actions spam / despam et les grands fossés qui existent dans l'historique de page. Il y a un gap de 10 jours entre la rev.39 et la rev.102 de ProblemSolving. C'est vraiment démotivant. -- HelmutLeitner

Je suis sûr que c'est un vrai frein ! J'ai installé Usemod 1.0 sur de mes sites : il conserve toujours la dernière version avant celle en cours. Usemod 1.0 a aussi les systèmes géniaux de feuilles de style et beaucoup de fonctionnalités améliorées. Peut-être que mettre à jour Usemod 1.0 sur Meatball pourrait être la solution à tous les problèmes actuels ?

Une autre solution sûr contre le feu. Je suis sûr que CliffordAdams accepterait de programmer une fonction similaire à celle qui existe sur C2 : réinitialiser à la version précédente. Ceci rend cette tâche de réinitialisaton vraiment facile et elle décourage vraiment les spammers. Pas de miracle ! Ils savent que cela nous prendra une demi-seconde à réinitialiser leur vandalisme aussi il s'ennuieront peu longtemps ! Cette fonction est essentielle sur un wiki public. Ne pas disposer de moyens rapides pour réinitialiser vers la version avant celle qui est spammée est un problème vraiment demandé. Par conséquent, je suis d'accord avec vous Helmut, réparer ce problème est très urgent. Pourquoi ne pas rentrer en contact avec Clifford et voir ce qui peut être fait ? Cette bêtise ne peut pas durer à jamais. RobertAbitbol?

-- RobertAbitbol?

: Robert, il n'y a nul besoin de ta part d'utiliser des mots durs. Cliff ne maintient pas le script mb, aussi suggérer cela veut dire offenser Sunir. Es-tu ici pour démarrer un autre combat ? S'il te plaît, collaborons en paix. -- HelmutLeitner

Oui je te dis quoi, Helmut ! Parce que tu es un diplomate génial et parce que tu peux presque tout gérer en paix bien mieux que je le peux, je te laisserai gérer. Réveille-moi quand quelques modificiations seront faites et quand le problème sera réparé (dans 10 mois). :-) -- RobertAbitbol?

PS : Tu deviens idiot quand tu présumes que je voulais offenser Sunir. Je n'avais pas connaissance qu'il maintenait le script. Ainsi parce que ta prémisse est fausse, tous les éléments en découlant sont aussi erronés ! Tes interprétations sont vraiment tirées par la queue et tu fais beaucoup d'hypothèses (fausses).

Maintenant, si tu me demandes, au lieu de patcher 0.92, je mettrais à jour vers 1.0 et ce serait la fin du problème. Bien sûr ceci pourrait blesser l'égo de Sunir, aussi nous de penserions même pas à ça et nous resterions avec nos problèmes avec le programme réinitialisant 40 versions avant !

: Je ne faisais pas d'hypothèses, je te posais une question. Merci de la réponse et pour la volonté de me laisser gérer. Je supposerais que le script mb a bifurqué, aussi il n'existe pas de moyen économique pour simplement le mettre à jour.

: Pourquoi n'essayes-tu pas de comminquer sans jeter des mots comme "idiot" ou des déclarations offensives comme ce "cela prendra à quelqu'un 10 mois pour trouver un bug ?" Un problème de logiciel est rapporté et en attente d'être résolu. C'est un événement de tous les jours, pas besoin de grandes émotions, tout spécialement de la part de quelqu'un dans le RôleInvité. -- HelmutLeitner

LangueFrançaise PageTranslation KeptPages

PagesConservées

Motivation

Solution

Discussion