Fossil:Dateien zu bestehendem Repo hinzufügen, muss ich sie zuerst öffnen?

Question

Ich möchte Versionen eines Verzeichnisses steuern, es "Projekt" nennen und die Fossilien in einem anderen Verzeichnis namens "Fossilien" behalten. Ich habe erfolgreich das Repository "project.fsl" erstellt, meine Projektdateien hinzugefügt, engagiert und geschlossen.Mein Problem besteht darin, zu verstehen, wie ich den nächsten Schritt machen soll.

Hier ist, was ich tue, indem ich dem folge fossilbook Vorschläge.

$ cd project
$ fossil new ../fossils/project.fsl
$ fossil open ../fossils/project.fsl
$ fossil add .
$ fossil ci -m "first commit"
$ fossil close project.fsl

Jetzt habe ich an meinem Projekt gearbeitet, einige Dateien bearbeitet, einige Dateien gelöscht, einige Dateien erstellt, einige Dateien umbenannt.Ich möchte den aktuellen Stand des Projekts zum Repository hinzufügen.Wie mache ich das?

Basierend auf dem, was ich im Dokument gelesen habe, hatte ich den Eindruck, dass ich zuerst das Repository öffnen, dann Dateien hinzufügen und dann einen Commit durchführen musste.Wenn ich das Repository nicht öffne, erhalte ich das Not within an open checkout. Nachricht.Aber wenn ich open Fossil möchte mein Verzeichnis mit den älteren Dateien überschreiben.(Und wenn ich von innen öffne fossils Verzeichnis, ich bekomme eine „entpackte“ Version meines Projekts, die in das Verzeichnis „Fossilien“ kopiert wird, was ich auch nicht möchte)

$ cd project
$ fossil open ../fossils/project.fsl

Hier möchte Fossil mein Projekt mit der älteren Version überschreiben.Ich sage zu jedem Vorschlag Nein.Ich vermute openwar nicht der richtige Ansatz, aber wenn nicht, was dann?

Ich möchte meine Änderungen zum Repository hinzufügen, also jetzt project.fsl open, ich versuche Folgendes:

$ fossil add .
 ADDED  Slides/tmp.tex

$ fossil commit -m "no idea what I'm doing, this will not end well"
 would fork.  "update" first or use --allow-fork.

$ fossil close
 there are unsaved changes in the current checkout

An dieser Stelle lösche ich alle genannten versteckten Dateien .fslckout .fossil und versuchen Sie es erneut, mit ähnlich enttäuschenden Ergebnissen.

Um ganz ehrlich zu sein, mein einziges Interesse gilt fossil führt eine Historie meines Projekts.Ich habe keine Co-Autoren und habe auch nicht vor, dies zu tun fossil diff oder fossil ui oder so etwas in der Art, bis ich mich irgendwann, was hoffentlich nie passieren wird, mit der Geschichte meines Projekts befassen muss.

Bearbeiten. Ich bin ein totaler Neuling.Ich bin mir nicht sicher, ob ich die Bedeutung verstehe checkout, manifest, leaf, usw.Deshalb fällt es mir trotz der unzähligen Stunden, die ich damit verbracht habe, es zu versuchen, sehr schwer, etwas aus dem Handbuch herauszuholen.Ich verstehe nicht viel von dieser Seite fossil open: http://fossil-scm.org/fossil/help/open

Answer 1

fossil open Ist das richtige tun.In Ihrem Fall ist es das fossil close das war nicht nötig.

An diesem Punkt sollten Sie es tun fossil open ../fossils/project.fsl --keep um Ihr Repo zu öffnen und dabei alle Änderungen beizubehalten.

Der offen Der Befehl markiert das aktuelle Verzeichnis als Arbeitsverzeichnis (in fossilen Begriffen, a Kasse).Ich empfehle Ihnen, es erst zu schließen, wenn Sie entweder Ihr Repo oder das Arbeitsverzeichnis selbst verschieben müssen.Persönlich passiert das nur, wenn ich auf einen anderen Computer wechsle.

Damit Fossilien alle Veränderungen identifizieren können, tun Sie es einfach fossil addremove;Fossil fügt dann alle neuen Dateien hinzu und entfernt alle gelöschten Dateien, sodass das Repository wieder mit dem Arbeitsverzeichnis übereinstimmt.Natürlich müssen Sie die Änderungen anschließend noch übernehmen.

Notiz Das addremove tut nicht Dateiumbenennungen automatisch erkennen!Wenn Sie Dateien umbenannt haben, sollten Sie Fossil dies für jede Datei mitteilen, die das verwendet fossil rename Befehl, Vor Du führst die aus addremove Befehl.Wenn es Ihnen nichts ausmacht, den Bearbeitungsverlauf bestimmter Dateien zu unterbrechen, können Sie das natürlich auch überspringen und Fossil glauben lassen, dass eine Datei gelöscht und stattdessen eine andere hinzugefügt wurde.

Answer 2

Niedrige Zeremonie und einfache Anfänge

Für einen einzelnen Entwickler kann der Lebenszyklus eines Fossillagers sehr einfach sein:

1. fossil new um die Repository-Datei selbst zu erstellen.
2. fossil open um den ersten (oder möglicherweise einzigen) aktiven Arbeitsbereich zu erstellen
3. fossil add, fossil remove, fossil rename Und fossil addremove um Fossil darüber auf dem Laufenden zu halten, welche Dateien verfolgt werden sollen.
4. fossil commit um Änderungen an das Repository zu übertragen

Dabei werden die Schritte 3 und 4 nach Bedarf während der gesamten Projektlaufzeit wiederholt.

Dies ist einer der größten Vorteile von Fossil:Es ist von Natur aus eine sehr niedrige Zeremonie.Man kann ein sehr aufwändiges Projekt alleine pflegen und wirklich nur nutzen fossil commit regelmäßig.

Nächste Schritte

Die nächste Stufe der Verfeinerung kann in mehrere Richtungen verlaufen.Wenn Sie die Arbeit an einem Projekt mit einem zweiten Entwickler teilen möchten, möchten Sie möglicherweise mehr über das Klonen eines Repositorys und das Synchronisieren von Updates erfahren.Wenn Sie unabhängiges Arbeiten an einer Funktion ermöglichen möchten, ohne Ihre Trunk-Builds zu beschädigen, können Sie mehr über Verzweigungen und Zusammenführungen erfahren.Wenn Sie die Wiki- und Ticket-Tracker-Funktionen nutzen möchten, sollten Sie sich darüber informieren fossil ui, fossil server oder konfigurieren Sie Ihren Webserver für den Start von Fossil.

Aber keiner dieser Anwendungsfälle wird es tun erfordern die Verwendung der fossil close Befehl.Tatsächlich ist die Ausgabe von fossil help wurde kürzlich in eine kürzere Liste von Befehlen, die von den meisten Benutzern benötigt werden, und eine längere Liste aller Befehle aufgeteilt.In dieser Abteilung fossil close kam nicht in die engere Wahl.Die einzigen Funktionen, die durch einfaches Löschen von Dateien nicht einfach ausgeführt werden können, bestehen darin, zu überprüfen, ob es sich dabei nicht um nicht gespeicherte Änderungen handelt, und den geöffneten Checkout aus Ihrer persönlichen Liste der für Sie verfügbaren Checkouts zu entfernen fossil all Befehl.

Fossilspezifischer Wortschatz

Sogar ein einzelner Entwickler möchte einige der Vokabeln lernen, die in der Fossil-Dokumentation verwendet werden.

• "einchecken":Ein bestimmter Satz von Dateirevisionen, identifiziert durch eine UUID und möglicherweise durch ein oder mehrere Tags.
• "Kasse":Ein zugeordneter Ordnerbaum (von fossil open) mit einem bestimmten Repository.Die meisten Fossil-Befehle erfordern, dass sich das aktuelle Verzeichnis in einem offenen Checkout befindet.
• „UUID“:Eine eindeutige Kennung für ein bestimmtes Objekt, das im Fossillager aufbewahrt wird.In der Praxis ist die UUID der SHA-1-Wert des Dings, ausgedrückt in Hexadezimalform.In den meisten Fällen kann die UUID auf gerade so viele führende Ziffern des vollständigen Hashs gekürzt werden, dass sie eindeutig identifiziert werden kann.Es wird normalerweise als 8- oder 10-stellige Zahl in eckigen Klammern geschrieben.
• "Artefakt":Eine Datei oder ein anderer Inhalt (eine Wiki-Seite, ein Ticket, ein Manifest usw.), die im Repository gespeichert ist.Jede Datei, die Sie einchecken, wird zu einem Artefakt.Dies gilt auch für alle Metadaten (Kommentare, Zeitstempel usw.) zu jedem Check-in.
• "Zweig":Eine Reihe aufeinanderfolgender Check-Ins, die von einigen Root-Check-Ins abzweigen.Zweige werden verwendet, um Änderungen beizubehalten, bis sie zum Zusammenführen bereit sind, oder um einfach fehlerhafte Änderungen aufzunehmen.
• "Blatt":Der Check-in am Ende einer Filiale.
• "Stamm":Der erste Zweig in jedem Repository heißt „Trunk“.Die meisten anderen Zweige werden Zweige von einigen Checkins entlang des Stammes sein.
• "Manifest":Die Liste der Dateien, die bei einem bestimmten Check-in geändert wurden, zusammen mit Metadaten, die diesen Check-in beschreiben (der Benutzer, die Zeit, die Beschreibung, die UUID des übergeordneten Check-ins und alle Tags, die er möglicherweise trägt), bilden das Manifest.Die meisten Benutzer müssen sich nicht wirklich um Manifeste kümmern, sie werden von ihnen erstellt fossil commit und kann über die Weboberfläche angezeigt werden.

Webinterface

Jeder Benutzer möchte mehr über die Webschnittstelle zu Fossil erfahren.Ein einfacher erster Schritt ist zu sagen fossil ui innerhalb einer offenen Kasse.Die Zeitleiste zeigt den Entwicklungsverlauf mit einem Knoten für jedes Einchecken und gezeichneten Linien, um Verzweigungen und Zusammenführungen anzuzeigen.Die Weboberfläche ist hochgradig konfigurierbar, bietet ein Wiki und einen Ticket-Tracker sowie eine GUI, über die die meisten Einstellungen im Zusammenhang mit dem Projekt und dem Repository angepasst werden können.

Fossil selbst ist ein effizienter Webserver für die Inhalte des Repositorys.Tatsächlich sind die meisten Seiten bei Offizielle Website von Fossil werden von Fossil selbst aus dem Repository für den Quellcode zu Fossil bereitgestellt.

Quellen für weitere Hilfe

Abgesehen von der Webseite und die einzelnen Befehlshilfen, die unter verfügbar sind fossil help, gibt es mehrere andere Ressourcen, die viele Benutzer kennen sollten.

Dort ist der Liste der Fossiliennutzer mit konstant hohem Signal-Rausch-Verhältnis.Die wichtigsten Entwickler achten darauf, ebenso wie viele hilfsbereite und sachkundige Benutzer.Die Liste enthält mindestens eine Archiv, sowie eine separate Liste für die Entwickler, um neue Funktionen und Pläne zu besprechen, aber fossil-dev wird nicht interessant sein, es sei denn, Sie möchten an den Interna von Fossil selbst arbeiten.

Jim Schimpf hat einen Buch Das soll sowohl ein Tutorial als auch eine vollständige Referenz sein und enthält einige Ratschläge zu Best Practices.Es lohnt sich, es zu lesen.

Die integrierte Befehlszeilenhilfe sowie die Dokumentation aller Seiten-URLs, die von der Weboberfläche verstanden werden, sind auch über die Weboberfläche von Fossil unter verfügbar /help URL innerhalb der Site eines beliebigen Repositorys.Dieser Hilfetext enthält eine Dokumentation aller Befehle, einschließlich der nicht unterstützten internen Testbefehle.

Und schließlich kann das [fossil tag][tag] hier bei StackOverflow als Ressource nicht ignoriert werden.