Versionskontrolle für die Zusammenarbeit (mit Unterschieden auf Wortebene)?

Die meisten Artikel werden jetzt gemeinsam verfasst, und die Mitarbeiter befinden sich häufig an verschiedenen Orten. Ich habe immer Versionskontrollsysteme für meine Dokumente und meinen Code verwendet und auch die Versionskontrolle als kritisch für kollaborative Softwareprojekte eingestuft, aber es scheint, dass viele Forscher theoretisch davon absehen, gemeinsame Arbeiten zu schreiben. Um meine Mitarbeiter davon zu überzeugen, dass die Versionskontrolle (Revisionskontrolle) eine gute Idee für die Zusammenarbeit ist, scheinen einige Voraussetzungen zu bestehen. Es ist nicht möglich, alle zu zwingen, sich Gedanken über bestimmte Konventionen für Zeilenumbrüche und Absätze zu machen oder Tabulator- / Leerzeichenkonvertierungen zu vermeiden.

Bietet jemand kostenloses Hosting für kleine freigegebene Dokument-Repositorys mit textdokumentfreundlicher Versionskontrolle an, die Unterschiede auf Wortebene ( nicht zeilenbasiert ) verarbeiten kann?

Wenn nicht, würde ich andere Vorschläge begrüßen, die auf Erfahrung basieren (bitte vermeiden wir Spekulationen).

Ich dachte an Git, Subversion, Mercurial, Darcs oder Bazaar, die für den Umgang mit Unterschieden auf Wortebene mit wdiff eingerichtet wurden, zusammen mit einer einfachen Methode zum Einrichten des durch öffentliche Schlüssel gesicherten Zugriffs (zum Beispiel über ssh). Allerdings scheint keiner der Versionskontrollanbieter, die ich mir angesehen habe, so etwas anzubieten. Für die wissenschaftliche Zusammenarbeit sind die von vielen dieser Unternehmen hervorgehobenen "Unternehmens" -Funktionen nicht sehr wichtig (viele Niederlassungen, Integration mit Trac, Prüfung durch Dritte, hierarchische Projektteams). Unterschiede auf Wortebene erscheinen jedoch kritisch, werden jedoch nicht unterstützt. Meiner Erfahrung nach muss bei Unterschieden auf Zeilenebene für Textdateien jeder vermeiden, Absätze und Editoren neu zu formatieren, die Tabulatoren in Leerzeichen ändern, oder umgekehrt, was zu Problemen führt. Es scheint auch viele falsche Bearbeitungskonflikte zu geben.

Siehe ähnliche Frage an MO über Tools für die Zusammenarbeit und die damit verbundene Fragen über bei TeX.SE, über die Versionskontrolle für LaTeX - Dokumente und LaTeX - Pakete für die Versionskontrolle . In der SVN-Hosting-Vergleichstabelle finden Sie eine große Liste von Hosting-Anbietern für nur eines der wichtigsten Versionskontrollsysteme.

Edit: Jukka Suomelas Antwort auf die TeX.SE-Frage " Beste LaTeX- fähige Diff- und Merge-Tools für Subversion " scheint der beste Vorschlag zu sein, der bisher die Interpretation der Deltas auf Wortebene behandelt . Darüber hinaus hat Jukka erklärt, wie die Unterschiede zwischen aufeinanderfolgenden Versionen auf der Repository-Seite von den Unterschieden auf Benutzerebene, die für die Konflikterkennung und das Zusammenführen von Änderungen verwendet werden, getrennt sind. Die Antwort von Jukka bei TeX.SE schließt gleichzeitige Bearbeitungen und Zusammenführungen ausdrücklich aus und verlässt sich stattdessen auf das traditionelle atomare Bearbeitungstoken, um Bearbeitungskonflikte zu vermeiden. Gibt es eine Möglichkeit, meine ursprüngliche Frage zu klären (und zu ändern), um sicherzustellen, dass Bearbeitungskonflikte auf der Basis von Wortunterschieden und nicht auf der Basis von Zeilenunterschieden gelöst werden können? Mit anderen Worten, kannwdiffoder ähnliche Tools in den Konflikterkennungsteil der Tools zur Versionskontrolle integriert werden, ähnlich wie Zeilenende- und Leerraumunterschiede ignoriert werden können?

Ich habe git verwendet, um an einigen in Latex geschriebenen Dokumenten zusammenzuarbeiten. Sie müssen einige Regeln einhalten:

• Beginnen Sie jeden Satz in einer neuen Zeile. Latex ignoriert diese Zeilenumbrüche, solange keine Leerzeile vorhanden ist
• Verwenden Sie die gleiche Konfiguration für die Formatierung (Tabulator / Leerzeichen / maximale Textbreite)
• Erstellen Sie für optimale Ergebnisse eine .gitattributes-Datei in Ihrem Repository und fügen Sie die Zeile hinzu *.tex diff=tex. Dies macht diff auf die Textsyntax aufmerksam und führt zu einer aussagekräftigeren Ausgabe.

Sie können dann git diff --color-wordsund verwenden gitk --color-words, um die Wortunterschiede anzuzeigen (siehe auch diesen Artikel Wortweise Unterschiede in Git zur Konfiguration von git, um immer den word-diff-Algorithmus zum Anzeigen des git diff / git-Protokolls zu verwenden).

Um das manuelle Zusammenführen zu reduzieren, kann ich empfehlen, separate Dateien für Abschnitte und Unterabschnitte zu verwenden (abhängig von der Größe Ihres Dokuments).

Ich schlage vor, einen Blick auf:

LaTeX / Gemeinsames Schreiben von LaTeX-Dokumenten ,

und das dazugehörige Papier:

Tools für das kollaborative Schreiben von wissenschaftlichen LaTeX-Dokumenten .

Ich möchte wirklich andere ansprechen und vorschlagen, dass Sie sich hinsetzen und eine nette SVN-Strategie ausarbeiten. Ich verwende SVN, um meine gesamte "Forschungs" -Struktur zu hosten:

• JabRef-Referenzverwaltung
• Heruntergeladene PDFs
• Artikel

Es ist großartig, weil es alles enthält und natürlich eine Geschichte liefert. Die Einschränkung ist, dass Sie Ihren eigenen Server benötigen. Wenn Sie jedoch einen vorhandenen Windows-Computer haben (oder was auch immer Sie möchten ), können Sie ihn einfach über VisualSVN Server installieren . Anschließend erstellen Sie geeignete Konten für Mitbearbeiter und gewähren ihnen Zugriff auf einen geeigneten Bereich (z. B. Lesezugriff auf Ihre JabRef-Bibtex-Datei und Lesen / Schreiben in einem gemeinsam genutzten Artikelbereich, der sich in Bearbeitung befindet).

TortiseSVN kann als Windows-Client für die Interaktion mit SVN verwendet werden. Sie müssen beim Verschieben / Löschen von Dateien und beim Kopieren von Ordnern vorsichtig sein (SVN speichert Metadaten in versteckten Ordnern in jedem Ihrer Ordner. Sie müssen also den Befehl delete in SVN ausführen, um sie zu entfernen. Dies ist etwas gewöhnungsbedürftig zu, aber die Investition lohnt sich).

Wenn sie dann mit einem Mitarbeiter zusammenarbeiten, müssen sie natürlich auch SVN verwenden. Aber auch hier ist die Investition in das Lernen nicht wertlos. Und über einige Gedanken können Sie es auch haben, so dass Sie nur Lesezugriff auf ihre Jabref-Datei haben (möglicherweise über die 'externe' Einrichtung in svn).

Auf diese Weise können Sie mit ein wenig Nachdenken und ein wenig Aufwand Dokumente wie gewohnt bearbeiten, Änderungen nachts vornehmen, morgens aktualisieren und alle Konflikte problemlos lösen.

Ich kann es nur empfehlen. Je mehr Leute ihre eigenen SVNs einrichten, desto besser, da dies in Zukunft nur die Optionen für die Zusammenarbeit verbessern wird (obwohl es natürlich von Vorteil wäre, wenn es vielleicht einen "Standard" für die Einrichtung eines wissenschaftlichen Archivs gäbe).

- Edit: Infact, ich habe einen solchen Vorschlag hier geschrieben: Strategie für die wissenschaftliche Zusammenarbeit mit LaTeX und SVN . Es wird vorgeschlagen, die Funktion svn externals zu verwenden, um eine einfache Zusammenarbeit zwischen Personen mit einer ähnlichen Konfiguration zu ermöglichen. Lassen Sie mich wissen, wenn es geändert werden muss oder einfach nicht angemessen ist.

Während ich Ihren großartigen Beitrag las und mich selbst nach einer Lösung umsah, stieß ich auf die Option, Änderungen auf Wortebene in gitk einzufärben . Der gitk-Parameter scheint eine neue und / oder undokumentierte Funktion zu sein, da die automatische Vervollständigung dies nicht bietet und die gitk-Manpage es nicht auflistet .
Hier sind die Optionen, die ich gefunden habe:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Sie können mehrere Diskussionen zu diesem Thema finden, die nach "diff --color-words" gitk suchen .

Edit:
So sieht es aus ...

Ich verstehe das Problem sehr gut. Ich habe angefangen, Kaleidoscope für Diffs mit Git zu verwenden. Es ist nur für Mac gedacht, aber die Vergleiche funktionieren besser als für wdiff. Außerdem verfügt es über eine Benutzeroberfläche und Live-Updates.