Hier gehen wir die subjektive Gasse hinunter ..
In letzter Zeit habe ich in einigen meiner Repositories eine Datei namens "whiteboard.txt" hinzugefügt. Ich benutze Mercurial, aber das gilt für alle DVCS.
Der Zweck der Textdatei ist es, Formate, Flüsse, Ideen usw. zu hashen. Angesichts der Tatsache, dass die meisten verteilten Versionskontrollsysteme irgendeine Art von Webschnittstelle haben, warum bezeichnen Sie nicht ein Verzeichnis als "Wiki" und lassen es zu als etwas angesehen und verwendet, wie Wiki Creole Markup?
Offensichtlich können nur diejenigen mit Commit-Zugriff Änderungen vornehmen.
Mein Punkt ist, wenn der Code fertig ist, wird das Design-Wiki und eine ganze Menge Dokumentation erstellt. Warum nicht die beiden wichtigsten kollaborativen Tools in einem integrieren?
Zum Beispiel, wenn ich könnte:
hg --wiki und finde den Grundgedanken hinter einer Gruppe von 30 Patches sowie deren beabsichtigte Richtung über die abgekürzten Kommentare hinaus im Commit-Log .. wow :) Jedes commit könnte einen Wiki-Eintrag referenzieren, außerdem werden Diskussionen Teil des Repositories und keine sekundäre Seite.
Wenn Sie einen DVCS verwenden möchten, weil Sie offline arbeiten können, warum ist das nicht sinnvoll?
BEARBEITEN:
Der springende Punkt wäre, wenn 'joe' eine Datei festschreibt, sollte er in der Lage sein, ein Attribut 'nag' zu setzen, das jeden anderen dazu auffordert, eine bestimmte Wiki-Seite zu aktualisieren Zukünftige Zusammenführungen haben sich hinter den Kulissen aufgelöst. Schließlich ist es Text, kein Code und kann als FIFO behandelt werden.
Wenn Sie offline arbeiten können, können Sie ein Wiki auch offline aktualisieren und Ihre Änderungen später auch im Patch-Format übernehmen.
Die Idee ist täuschend einfach.
Es gibt ein Projekt namens Fossil , das genau das tut. Ich habe es nicht persönlich benutzt, aber es wurde von derselben Person erstellt, die auch SQLite geschrieben hat, also bin ich davon ausgegangen, dass es klein und schnell ist. In der Tat ist laut der Website alles in einer kleinen SQLite-Datenbank gespeichert, so dass es einfach zu archivieren und zu transportieren sein sollte.
Gute Idee, aber ich würde das Wiki in einem separaten Repository aufbewahren.
Ähnlich wie Bitbucket.org (wenn Sie einen Zweig registrieren, erhalten Sie zwei hg-Repositories, einen für die Quelle und einen für das Wiki ).
Um Ihre Commits mit Informationen darüber zu versehen, was getan wurde und warum, verwende ich unter anderem ein Issue-Tracking-System wie
Wenn Sie jetzt Quellcode und Problemverfolgung zusammenführen möchten, wie Mylyn , wenn Sie ein Eclipse-Entwickler sind Ihre IDE dann "Magie" beginnt zu passieren. Ich habe gesehen, wie Visual Studio Team System mit Problemverfolgung und Versionskontrolle arbeitet, aber ich muss sagen, dass ich mehr beeindruckt bin, wie Mylyn damit umgeht (da es auch offline mit Problemen arbeiten kann).
Tags und Links version-control