Einfache Versionierung für Klartextdokumente (Linux)

Ja, Sie sollten git* verwenden.

Lassen Sie mich jetzt erklären, warum. Angesichts der aktuellen (ziemlich nebulösen) Kriterien in Ihrer Frage scheint die Antwort ziemlich offensichtlich zu sein. Wenn Sie mehr wüssten, würden Sie diese Frage nicht einmal stellen. Sie haben sich bereits an den Rand der Klippe gebracht, jetzt müssen Sie nur noch überreden, den Sprung zu schaffen.

_{* Oder Fossil, Mercurial, Darcs, Bazaar oder andere DVCS, je nach dem von Ihnen bevorzugten Front-End-Tooling, das erklärt werden muss.}

Die aktuelle Szene und etwas Geschichte:

Grundsätzlich gibt es drei Arten von Versionskontrollsystemen: Distributed , Ham-fisted und Tapped-out . Erlauben Sie mir, auf diese technische Terminologie einzugehen und wie sie entstanden sind und auf Ihre Situation zutreffen würden.

• Schinkenfaust

  Bemerkenswerte Einträge*: CVS, Subversion.

  Bevor DVCS-Systeme die Welt im Sturm eroberten, gab es VCS-Systeme. Diese könnten durch ein zentrales Repository/Server und ein sternförmiges Muster von Benutzer-Arbeitsbereichen/Clients gekennzeichnet sein. Diese waren ein unverzichtbar wertvolles Werkzeug, um ein Team von Programmierern auf der gleichen Seite zu halten, und passten sich sogar anderen Anwendungen an. Ein einzelner Programmierer könnte von mehreren Systemen aus arbeiten und mit Verzweigungen und Tags herumspielen. Sie haben viele Tage gerettet. Aber sie waren von Natur aus ungeschickt. Sie machen einige einfache Aufgaben schwieriger . Zuerst gab es den Aufwand für die Einrichtung, die Notwendigkeit eines Servers und spezifischer Protokolle, um sie zu verbinden. Dann war da noch der Schmerz, mit diesen Zeiten fertig zu werden, in denen Sie etwas falsch gemacht haben. Es genügt zu sagen, dass diese die Arbeit für Ihren Anwendungsfall erledigen würden, aber Kompromisse einführen würden, die das Leben komplizierter machen würden.

• erschöpft

  Bemerkenswerter Eintrag: RCS.

  Denn als ein "ausgewachsenes" System mit Servern und Clients und Authentifizierung und all dem Jazz zu viel war, um es zu schlucken, war es möglich, ein abgespecktes System zu verwenden, das in seiner eigenen kleinen Blase lebte. RCS tat dies, indem es die Idee eines Repositorys vermied und nur eine Datei nach der anderen versionierte. Sie hatten file.txtund saßen direkt daneben eine file.txt,vmit der Versionshistorie. Sie können es einfach pro Datei instanziieren und eine Handvoll einfacher Tools verwenden, um mit Diffs zu arbeiten, Zeit zurückzusetzen usw.

  Bevor Sie jetzt sagen: "Aha, genau danach habe ich gesucht!", lesen Sie bitte weiter, da dies nicht mehr der einfachste oder empfohlene Weg ist, dies zu tun. Der einfache Einstieg ging mit einer niedrigen Betriebsobergrenze einher, die Ihren Stil früher oder später mit ziemlicher Sicherheit einschränken wird.

• verteilt

  Irgendwann entschied ein Haufen kluger Programmierer, dass sie genug von den Schmerzen hatten und sagten: "Wir werden Kuchen essen und ihn auch haben." Erstaunlicherweise waren sie erfolgreich und verteilte Versionskontrollsysteme wurden geboren. Diese Systeme kombinieren das Beste aus beiden Welten – einen vollständigen Versionsverlauf, der sich auf Ihrem lokalen System direkt neben den Originaldateien befindet, sowie die Möglichkeit, Ihren Verlauf zu teilen und mit dem anderer Remote-Repositories zu interagieren. Es stellt sich heraus, dass dies keine ernsthaften technischen Nachteile mit sich bringt.

  Als größte Hürde für einige Shops stellte sich die Flexibilität heraus. Da die Systeme Ihre Arbeitsweise nicht willkürlich einschränken, ist es manchmal schmerzhaft, von einem System zu migrieren, das Sie zu einem bestimmten Arbeitsablauf gezwungen hat. Plötzlich müssen Sie ein wenig darüber nachdenken, wie Ihr System funktionieren soll. Viele Dinge, die früher erforderlich waren (zentraler Knoten, der immer die neuesten Sachen von allen hat), wurden zu einer Angelegenheitskonvention, die nur dann verwendet werden sollte, wenn Sie es wünschen, aber Sie müssen sich hinsetzen und sagen: "So werden wir dieses Tool verwenden."

Setzen wir uns also hin und sagen, wie Sie dieses Tool verwenden würden.

Für die Zwecke dieser Antwort werde ich mich an Git halten, da es eines der am weitesten verbreiteten Systeme ist. Es ist auf fast jedem System einfach zu installieren (falls es nicht bereits installiert ist) und es ist eine breite Palette an Dokumentation verfügbar, die fast jeden Anwendungsfall abdeckt. Es ist auch erweiterbar und wird von vielen Drittanbietersystemen usw. erkannt. Davon abgesehen ist es nicht unbedingt besser als seine nächste Konkurrenz, Bazaar oder Mercurial.

• Wenn Sie in einem Ubuntu-Ökosystem leben, möchten Sie vielleicht einen Blick auf Bazaar werfen, da Canonical es für alles verwendet und sich gut in Ihre Umgebung integrieren lässt. Ihr Launchpad -Dienst ähnelt Github, ist jedoch auf die Ubuntu-Softwareentwicklung zugeschnitten. Wenn Sie vorhaben, in diesem Ökosystem zu spielen, ziehen Sie das Lernen bzranstelle von Git in Betracht, damit ein Tool sowohl für Ihre persönliche Welt als auch für das Ökosystem, an dem Sie teilnehmen, funktioniert. Wenn Sie nicht an Projekten arbeiten, die auf dem Launchpad koordiniert werden, würde ich vorschlagen, Git zu verwenden.

• Wenn einer Ihrer Kollegen Mercurial mag, sollten Sie sich überlegen, ob Sie es verwenden möchten. Es ist ein sehr leistungsfähiges DVCS mit einigen Vorteilen gegenüber Git. Es wird häufig behauptet, dass es für einige Vorgänge aufgrund eines optimierten Datenflusses schneller ist. Die Tools sind alle in eine einzige Binärdatei verpackt, anstatt aus einer Reihe separater (und manchmal redundanter) Tools zusammengepfercht zu werden, wie es bei Git der Fall ist. Es ist mit Python-Bindungen erweiterbar und es ist möglich, externe Systeme zu erstellen, die sich sehr eng damit integrieren lassen. Das Paradigma ist Git ähnlich genug, dass Sie sich, sobald Sie es gelernt haben, auch in einem Git-Repository zurechtfinden können. Letztendlich ist Git jedoch derzeit der beliebteste Spieler auf dem Gebiet, und wenn Sie dabei bleiben, haben Sie einen leichteren Zugang zu Hilfe, wenn Sie sie brauchen.

_{* Ich entschuldige mich bei allen nicht genannten VCS-Systemen. CVSNT, CA, CC, Perforce, Plastic, PVCS, Star, SVK, Vault, Vesta, VSS und viele andere. Ihre Namen werden nie vergessen werden sind bereits nur eine Erinnerung.}

Wie gitpasst Ihr Anwendungsfall:

Sie haben erwähnt, dass Sie Github ein wenig verwendet haben. Das ist großartig, aber Sie müssen bedenken, dass Github nicht git ist . Es ist ein weit verbreiteter Irrglaube, dass das, was sie anbieten, eine kostenlose Möglichkeit ist, in das System einzusteigen, indem sie Ihre Repositories für Sie hosten. In Wirklichkeit bieten sie eine Schicht an, die auf Git aufgebaut ist und teils soziale Netzwerke und teils Projektmanagement umfasst. Dies ist eine großartige Sache für die Open-Source-Community. Anstatt zu versuchen, ein alternatives System zu sein und den Markt zu bekämpfen, haben sie auf brillante Weise ein gutes Werkzeug eingesetzt und einen Markt geschaffen, der einen Mehrwertdienst für Unternehmen bietet und gleichzeitig der Gemeinschaft dient. Aber Github ist kein Git.

Git kann tatsächlich viel einfacher verwendet werden.

Ähnlich wie RCS speichert Git die Versionsinformationen lokal direkt neben Ihren Inhalten. Der bemerkenswerte Unterschied von Anfang an besteht darin, dass dies auf Verzeichnisbasis und nicht auf Dateibasis erfolgt.

• RCS:

    file1.txt
    file1.txt,v
    file2.txt
    file2.txt,v
  

  Die ,vDatei für jede Datei führt eine fortlaufende Liste des Dateiverlaufs und speichert das Delta zwischen jeder aufeinanderfolgenden Version.

• Git:

     directory
     + file1.txt
     + file2.txt
     + .git
       + glob1
       + glob2
  

  Das Zeug im .git-Ordner hat eigentlich verrückte Namen und ist ziemlich kompliziert, aber Sie müssen nichts darüber wissen. Konzeptionell speichert es lediglich die Unterschiede zwischen den Versionen von Inhalten in Ihrem Verzeichnis. Grundsätzlich ist jeder Glob ein Abbild dessen, wie Ihr Verzeichnis zum Zeitpunkt jedes Commits aussah. Viel ausgefallene Mathematik hält den Overhead niedrig, sodass nur die Delta-Daten gespeichert werden.

Das mag sich jetzt schon kompliziert anhören, aber das müssen Sie wirklich nicht wissen. Das Tool-Set behält für Sie den Überblick über all die ausgefallenen Dinge. Die grundlegende Verwendung ist sehr einfach wie RCS, gibt Ihnen aber Raum, um später zu wachsen.

Der Einstieg würde in etwa so ablaufen:

# Change to the directory that has files you want to version.
cd ~/pathto/yourtextfiles

# Initialize git to keep track of that folder
git init

Fertig. Keine Server erforderlich. Nur Sie und Ihre versionierten Dateien. Außer, dass Sie noch keine Dateien überwacht haben, also beobachtet Git eigentlich nichts. Git ist nicht gierig in dem Sinne, dass es nicht alles in einem Ordner verfolgt, sondern nur die spezifischen Dinge, die Sie ihm mitteilen. Der nächste Schritt besteht also darin, ihm mitzuteilen, welche Dateien Sie verfolgen möchten.

# Add some files to the system, assuming these already exist the your dir
git add file1.txt file2.txt

# Commit the changes you just made
git commit -m "initial add"

Beachten Sie, dass dies im Gegensatz zu den meisten Systemen ein zweistufiger Prozess ist. Bevor Sie Dinge committen und sie als neue Version in das Repository stopfen, müssen Sie sie „stagnieren“. Nicht jede Änderung, die Sie an Ihrem Arbeitsverzeichnis vornehmen, wird automatisch als etwas angenommen, in das Sie bei jedem Commit speichern möchten. Vielleicht haben Sie zwei Dateien geändert, möchten aber nur eine markieren.

# Edit a bunch of files
vim file1.txt
vim file2.txt
vim file3.txt

# Only mark one of them as going it your next commit
git add file2.txt

# Commit it to history
git commit -m "fixed typo"

Beachten Sie, dass die Änderungen an file1.txt noch nicht im Repository gespeichert sind und file3.txt überhaupt noch nicht verfolgt wird. Sie können sehen, dass eine zuvor nachverfolgte Datei Änderungen ohne Staging aufweist, indem Sie sie ausführen, git statusund was diese Änderungen sind, indem Sie sie ausführen git diff. Dieser Punktstatus würde Ihnen mitteilen, dass Sie Änderungen an file1.txt vorgenommen haben und dass es eine nicht verfolgte file3.txt in Ihrem Verzeichnis gibt. Diff würde Ihnen die Änderungen zeigen, die Sie an file1.txt seit dem letzten Staging und Commit vorgenommen haben.

Ein 'Gotcha', vor dem Sie gewarnt werden sollten, damit es Sie nicht auf der Straße beißt, ist das - weil Gits Konzept eines Repositorys ein ganzes Verzeichnis ist und die Änderungen an Dateien als Abbild dieses Verzeichnisses bei a gesehen werden Zeitpunkt – Sie sollten erwägen, separate Repositories für unterschiedliche Projekte zu haben. Anstatt ein einzelnes Repository aus "Eigene Dateien" zu erstellen, sollten Sie separate Repositorys aus Verzeichnissen erstellen, die eine sinnvolle Teilmenge Ihrer Dokumente enthalten, sei es pro Thema oder pro Format oder pro Projekt oder was auch immer. Dies macht es später einfacher, wenn Sie mit „allen Dokumenten im Zusammenhang mit x“ von einem anderen Computer aus arbeiten möchten, ohne jedes Dokument, das Sie jemals erstellt haben, auf diesem Computer haben zu müssen. Git nicht erlaubtWenn Sie einen Teilbaum eines Repositorys* auschecken, geht es um alles oder nichts, also machen Sie lieber viele granulare Repositorys für eng verwandte Datensätze, eines pro Verzeichnis.

Das ist wirklich alles, was zur grundlegenden Verwendung gehört. Von dort aus ist fast alles möglich, was Sie sich vorstellen können, aber an diesem Punkt würden Sie eine Nutzungsfrage stellen, keine Softwareempfehlungsfrage.

_{* Subversion zum Beispiel erlaubte dies und ich gewöhnte mich daran. Das hat mich schon früh gebissen, als ich annahm, Git würde etwas Ähnliches zulassen. Ich hatte ALLE meine persönlichen Dateien in einem großen SVN-Repo und nahm naiv an, dass Git ein Drop-in-Ersatz dafür sein würde. Lektion gelernt, und meine Dateien sind besser dran, wenn sie kategorisiert werden.}

Aber Eingabeaufforderungen sind beängstigend!

Es gibt natürlich eine Vielzahl von Front-End-GUIs, die Sie von der Befehlszeile fernhalten und visuell darstellen, was mit Ihren Dateien vor sich geht. Viele davon haben einen IDE-ähnlichen Geschmack und könnten als Einstiegspunkt in die Dokumentenverwaltung dienen, indem Sie sie verwenden, um Ihren Lieblingseditor* zu starten oder sogar einen integrierten zu verwenden. Da Sie nach dem Backend gefragt haben, wie Ihre Dateien gespeichert werden sollen, habe ich eine Empfehlung zur Verwendung gitals Versionsmanager abgegeben, aber wenn Sie sich vorstellen, wie dies aus Frontend-Perspektive aussehen und funktionieren sollte, sollten Sie fragen das als separate Frage.

_{* Wäre für diesen Anwendungsfall natürlich gvimgut geeignet ;-)}

Abschließend:

Komm rein, das Wasser ist gut!

Einer! Zwei! Drei! Springen git init .

Sehen Sie, das war nicht so schwer.

Ich würde in diesem Fall raten, https://draftin.com/ zu verwenden , siehe hier für einen kurzen Blick auf die spezifischen Funktionalitäten, die Sie möglicherweise verwenden möchten.

Ein Nachteil dieser Software, auf den ich hinweisen möchte, bevor ich eine detaillierte Antwort auf Ihre Frage gebe, ist, dass sie für die Online-Nutzung gedacht ist. Es ist möglich, Draft ohne Internetverbindung zu verwenden (siehe hier ), aber es muss noch poliert werden - die Synchronisierung, die ein wesentliches Feature in Draft ist, muss immer noch von Hand ausgelöst werden, bevor es offline geht.

1. Versionskontrolle: JA , auf jeden Fall. Es ist eine Kernfunktion im Entwurf, und es ist großartig, da es nicht im Weg steht, wenn Sie es nicht sehen möchten, aber es ist da, um Ihnen jedes Mal zu dienen, wenn Sie – oder jemand, mit dem Sie Ihr Schreiben teilen – Chaos verursachen her mit dem Dokument. (Standardmäßig sind die Bearbeitungen anderer nicht in Ihren Versionen des Dokuments enthalten, Sie müssen sie vorher akzeptieren.)

2. Ubuntu/Mint-freundlich: JA , es ist immerhin eine Website. Jeder anständige Browser wird es tun, ich habe die Offline-Funktion nur auf Chromium getestet, das ein PPA für Ubuntu hat.

3. Einfaches Markieren/Kommentieren/Kennzeichnen: NEIN . Der Punkt ist, dass der Entwurf dies für Sie erledigen sollte, indem er Ihnen erlaubt, Haupt- und Nebenversionen Ihrer Dokumente zu markieren und klarzustellen, wer die Änderungen vorgenommen hat. In diesem Punkt wäre Entwurf nicht das beste Werkzeug für Sie.

4. Einfaches Tag/Label-Browsing, Suche: nicht sicher . Nun, zumindest wenn die Tag-Entwurfssets für Sie Ihren Anforderungen entsprechen.

5. Einfache "Wiederherstellung" früherer Versionen: JA . Sie können nicht nur frühere Versionen wiederherstellen, sondern auch die nützlichen Bits in beiden Versionen behalten und die aktuelle Version bearbeiten, während Sie den Unterschied mit anderen Versionen anzeigen.

6. Möglichkeit, Diffs zu machen: JA . Das Ding wird manchmal falsch (der ärgerlichste Fall wäre, wenn ich einen Absatz umschreibe: draftin glaubt, ich ersetze jeden Satz durch einen neuen, vermische das Alte und das Neue im Diff, wenn ich es vorziehen würde, den neuen Absatz von dem zu trennen alt, aber die Farbcodes machen es weniger schrecklich, damit umzugehen.) Diffs funktionieren jedoch gut.

7. Möglichkeit der Synchronisierung mit verschiedenen Maschinen: JA , aufgrund der Webseitennatur der Sache. Der Offline-Modus ist jedoch seltsam und erfordert eine manuelle Synchronisierung.

8. einfache Verzeichnisstruktur/Hierarchie für Dokumente: JA, aber sogar etwas zu einfach. Sie können Dokumente in Ordnern ablegen, aber ich muss noch einen Weg finden, Ordner zu verschachteln, was ein großer Nachteil ist.

Zusammenfassend lässt sich sagen, dass der Entwurf den Benutzern seinen Weg aufzwingt, was cool ist, wenn Sie es mögen (ich liebe es). In Ihrem Fall ist es sicherlich einen Versuch wert, aber seine sehr geringe Flexibilität (es bietet jedoch eine API, wenn Sie auf Codierung stehen) könnte seinen Umfang einschränken.

Verwenden Sie „ Fossil “

@Calebs hervorragende Arbeit der Supererogation (oben) ist immer noch sinnvoll und fesselnd zu lesen, Jahre nachdem er sie veröffentlicht hat.

Nachdem ich jedoch sieben Jahre lang daran gearbeitet habe, ein System zu bekommen, das ich liebe, habe ich es in Fossil gefunden . Es ist ein- oder zweimal in SoftwareRecs aufgetaucht, fliegt aber tendenziell unter dem Radar (IMO).

Für diesen Benutzer beantwortet Fossil alle Vorteile, die Caleb in Bezug auf ein Git-basiertes System dokumentiert hat, und fügt ein paar Vorteile für meine Gehirn-/Arbeitsgewohnheiten hinzu . Und es antwortet wunderbar auf meinen ursprünglichen Anwendungsfall/Kriterien (natürlich):

• Versionskontrolle (natürlich unerlässlich!)
• Ubuntu/Mint-freundlich (PPA wäre toll) | aber kein PPA erforderlich!
• Einfaches Taggen/Kommentieren/Kennzeichnen von "Commits"
• einfaches Tag/Label-Browsing
• einfache Tag/Label-Suche
• einfache "Wiederherstellung" früherer Versionen
• Möglichkeit, Diffs zu machen
• Möglichkeit der Synchronisierung mit verschiedenen Maschinen
• einfache Verzeichnisstruktur/Hierarchie für Dokumente

Zusätzliche Vorteile

Es gibt im Wesentlichen zwei Vorteile für mich – (nb erfahrene Git-Benutzer werden davon nicht beeindruckt sein):

1. Fossil ist einfach selbst zu hosten . Dies mag auch für Git gelten , aber es scheint mir, dass Fossil einfacher selbst gehostet werden kann als Git. <shrug/>Obwohl dies nicht eines meiner wesentlichen Kriterien aus meinem ursprünglichen Beitrag ist, habe ich mich für diesen Ansatz entschieden (dh mich nicht auf Dienste von Drittanbietern zu verlassen).
2. Während die Prozesse denen von Git sehr ähnlich sind , scheint mir der Ansatz von Fossil (wieder) etwas schlanker (oder einfacher) zu sein, so dass einige der Ängste, die ich im Laufe der Jahre bei der Verwendung von Git erlebt habe (so wie ich), a sind kein Problem.
3. Bonus! Es ist auch sehr einfach, plattformübergreifend zu verwenden (ich wechsle regelmäßig zwischen Ubuntu und MacOS); Auch hier kann Git natürlich auf jeder Plattform verwendet werden, aber die Einstiegsbarriere scheint auf Nicht-Linux-Systemen für Git etwas höher zu sein als für Fossil.
4. Prämie 2! Fossil wurde als „GitHub-in-a-Box“ beschrieben, da seine einzelne ausführbare Datei (einfache Installation in Win/MacOS/*nix-Systemen) nicht nur Versionskontrolle, sondern auch Problemverfolgung, Wiki, Forum, einen „Chat "-ähnliche Einrichtung und ein integriertes Web-Frontend ... alles in einem. Freudig! (Nicht, dass man diese zusätzlichen Funktionen verwenden müsste, aber sie sind sozusagen ohne zusätzliche Kosten vorhanden.)

Calebs (sicherlich!) augenzwinkernde Bemerkung über Fossil (unter anderem) ("Ihre Namen werden nie vergessen werden, sind bereits nur eine Erinnerung.") trifft wahrscheinlich nicht auf Fossil zu ... es ist das, was die SQLite-Entwicklung verwaltet , wird also nicht so schnell verschwinden!:)

git ist eine gute Lösung für die Versionskontrolle. Speziell für Klartext.

• Untersuchen Sie die in ReText integrierte Unterstützung für Versionskontrollsysteme. (kann ich nicht finden)
• Probieren Sie Git-Frontends aus. Ich mag Git-Cola.
• Probieren Sie externe Diff/Merge-Tools aus. Ich mag Meld.