[linux-l] Re: Wiki-Grundsatz-Diskusion

[Volker Grabsch]

On Wed, May 17, 2006 at 07:45:30AM +0000, Rocco Rutte wrote:
> * Olaf Radicke [06-05-17 02:22:09 +0200] wrote:
> 
> >Leute ich glaube ihr mach ein grundlegenden Fehler. Ihr übertragt die 
> >Anforderungen an einer Versionskontrole für Quell-Code 1 zu 1 auf 
> >Text-Dokumente.

Rocco hat schon fast alles gesagt: Gemeinsame Arbeiten am Quellcode
haben im Prinzip die gleichen Probleme. Ich möchte aber noch ein
paar Details ergänzen.

Zum einen finde ich Olafs Vergleich zu Quellcode reichlich unpassend.
Sicher ist es nett, bei einem Projekt via Wiki auch "mal schnell
unterwegs" auch ein paar Codezeilen zu ändern (z.B. von kleinen
Shell-Scripten). Aber das hatte ich niemals im Hinterkopf.

Wie ich schon zigmal gesagt habe, geht es in meinen Betrachtungen
um Projekt-Dokumentationen. Diese sind überwiegend Fließtext, und
bis auf die Tatsache, dass das Thema eher technisch ist, und weniger
Leute daran arbeiten, gibt es keinen allzu großen Unterschied zur
Wikipedia, vorallem nicht was Merges/Konflikte angeht.

Beides sind Sachtexte, manchmal steht in der Wikipedia zu einer
Software sogar ein bessere Dokumentation (zur Einführung), als in
der offiziellen Doku dieser Software.

> Für ein Wiki bleibt die Frage ob man da ein vollwertiges und 
> ausgewachsenes SCM wirklich dringend brauch natürlich, aber man kann es 
> ja probieren.

Auf jeden Fall gibt es noch etliche sehr praktische SCM-Funktionalitäten,
die für Wikis sehr wünschenswert sind.

Ich stimme Olaf insofern zu, dass Branches bei Wikis eher selten
sind. Mehrere Entwicklungs-Versionen, die man dann später "merged", das
ist eher untypisch für Wikis, erst praktische Versuche können zeigen, ob
es sinnvoll ist oder nicht.

Was aber dem MediaWiki-SCM auf jeden Fall fehlt sind Merges und gute
Konfliktbehandlung. Ein Konflikt tritt immer dann auf, wenn zwei Leute
an sich überschneidenen Stellen etwas ändern.


Wenn also jemand im ersten Absatz Rechtschreibfehler korrigiert, und ein
anderer im zweiten Absatz etwas ergänzt, kann man das problemlos
zusammenfügen. Das verhält sich ganz genauso bei Dokumentationen und bei
Quellcode. Wenn sowas nicht automatisch zusammengefügt werden kann, ist
das reine Schikane.


Arbeiten hingegen zwei Leute an der selben Stelle, aber haben noch mehr
geändert, so können doch schonmal die Bereiche zusammengeführt werden,
die jeweils nur einer von ihnen bearbeitet hat. Nehmen wir an:

    A bearbeitet Kapitel 1 und 2
    B bearbeitet Kapitel 2 und 3

A lädt hoch. B will hochladen, bekommt einen Konflikt. Wieso muss B
seine Änderungen von Kapitel 3 mit eintragen? Der Konflikt bezieht sich
doch nur auf Kapitel 2.

Konflikte haben bei Enzyklopädien, Dokumentationen und Quellcode immer
die gleiche Ursache: Mangelhafte Absprache. Und dagegen hilft natürlich
nur Diskussion und Einigung darüber, wie es werden soll. Kein Merge-Tool
kann das einem abnehmen, das wurde schon an anderer Stelle erklärt.
Merge-Tools helfen einem nur bei den trivialen Angelegenheiten, aber das
sehr gut. Mit "trivial" meine ich ein einfaches Zusammenschneiden von
Zeilen. Meiner Erfahrung nach kommt das bei Fließtext und bei Quellcode
etwa auf das gleiche heraus.


Nun zu einem anderen Beispiel, deinem Beispiel: Einer ändert die Struktur,
ein anderer ein Detail. Bei Quellcode hat man an dieser Stelle ein
großes Problem. Bei Fließtext eher selten: Wenn z.B. nur die Absätze
umgeordnet wurden, dann kann das Merge-Tool oftmals den alten Kontext
wiederfinden und die Detail-Änderung landet trotz Struktur-Änderung noch
an der richtigen Stelle. Schiebt man hingegen Teile von einer Datei in
eine andere (bzw. von einem Artikel in einen anderen), hat man auf jeden
Fall verloren. Mit einem Merge-Tool hat man wenigstens noch eine Chance.
Mit der primitiven MediaWiki-Methode ist man erschossen. Auch hier würden
also dem MediaWiki bessere SCM-fähigkeiten gut tun.


Für ein gemeinsames Protokoll spielt das natürlich keine Rolle, weil
Merges und Konfliktbehandlung nunmal Clientseitig gelöst werden müssen.
Lediglich Branches bräuchten Protokoll-Erweiterungen, aber da diese in
den verschiedenen SCM so unterschiedlich gelöst wurden, und für
Ansammlungen von Texten (Wikipedia, Dokumentationen) ohnehin nicht so
wichtig sind, würde ich das bei einem übergreifenden SCM-Protokoll
erstmal außen vor lassen.

Selbst wenn es sich einfach in das Protokoll integrieren ließe, würde
ich diese Funktionalität auf jeden Fall optional gestalten, schließlich
soll es man mit erträglichem Aufwandt auch noch selbst implementieren
können. Ein Wiki-Server (und auch ein Wrapper für existierende SCM)
sollte die Wahl haben, ob er Branches unterstützt oder nicht.


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR