Versionskontrollierte gepackte Dateien (docx, odt)

Question

Es gibt Formate, die eigentlich getarnte Zip-Dateien sind, z. B. docx oder odt. Wenn ich sie direkt in der Versionskontrolle speichere, werden sie als Binärdateien behandelt. Meine ideale Lösung wäre

• haben einen Haken, der eine foo.docx/ Verzeichnis für jedes foo.docx Dateien vor der Übergabe, wobei alle Dateien in den Ordner entpackt werden
• optional mit einem Hook, der die Xml-Dateien neu einordnet
• haben einen Haken, der die foo.docx aus den gespeicherten Dateien nach der Aktualisierung

Ich möchte nicht, dass die docx-Dateien selbst versionskontrolliert sind. (Ich bin mir bewusst, dass ein zugehörige Frage wo ein anderer Ansatz mit einem benutzerdefinierten Diff vorgeschlagen wurde).

Ist das machbar? Ist dies mit Mercurial machbar?

UPDATE:

Ich kenne mich mit Haken aus. Ich bin an den Einzelheiten interessiert. Hier ist eine Sitzung zur Demonstration des erwarteten Verhaltens.

> hg add foo.docx
> hg status
A foo.docx
> hg commit
> # Change foo.docx with external editor
> hg status
M foo.docx
> hg diff
+++ foo.docx/word/document.xml
- <w:t>An idea</w:t>
+ <w:t>A much better idea</w:t>

Answer 1

Ich habe mich das gleiche gefragt und bin gerade auf die ZipDoc Erweiterung/Filter für Mercurial gestoßen, die anscheinend genau das macht!

Habe es noch nicht ausprobiert, aber es scheint vielversprechend zu sein!

Answer 2

Wenn es Ihnen gelingt, die Openoffice-Dokumente erfolgreich zu entpacken und zu komprimieren, sollten Sie in der Lage sein, das Filter-System zu verwenden, das wir in Mercurial haben. Damit können Sie Dateien bei jedem Lese- und Schreibvorgang im Repository transformieren.

Leider müssen Sie mehr tun, als nur die Datei foo.docx zu entpacken. Das Problem ist, dass Sie eine einzelne Datei als Ausgabe generieren müssen - also können Sie vielleicht unzip foo.docx und dann die generierten Dateien mit tar verpacken. Dann versionieren Sie den Tarball, was funktionieren sollte, da ein Tarball einfach eine unkomprimierte Aneinanderreihung aller individuellen Dateien mit einigen Metainformationen ist. Wenn man genauer darüber nachdenkt, wäre eine einfachere Lösung, die ausgepackte foo.docx-Datei erneut zu zippen, aber ohne Komprimierung anzugeben. Das sollte ähnliche Ergebnisse liefern wie die Verwendung von tar.

Die Lösung dieses Problems ist etwas, das ich selbst tun wollte, also melden Sie sich bitte zurück, indem Sie eine E-Mail an die Mercurial-Mailingliste senden.

Answer 3

Sie können einen Precommit-Hook verwenden, um zu entpacken, und einen Update-Hook verwenden, um zu zippen. Siehe den definitiven Leitfaden dazu, wie man Hooks verwendet.

Seien Sie vorsichtig mit Umbenennungen. Wenn Sie foo.docx in bar.docx umbenennen, muss Ihr Precommit-Hook foo.docx/ löschen und bar.docx/ hinzufügen.

---

UPDATE (Entschuldigung, dass ich einem Benutzer mit 1k-Reputation eine Einstiegsantwort gegeben habe)

Wenn Sie entpackte docx für grundlegende hg-Operationen wie diff verwenden möchten (status kann mit gepackten Dateien arbeiten), müssen Sie eine Erweiterung verwenden. Ich denke, Sie können einen ähnlichen Ansatz wie bei der keyword-Erweiterung wählen, um das Repo-Objekt mit Ihrem eigenen zu umhüllen.

Ich habe einige Erweiterungen geschrieben, aber nicht auf diesem Hardcore-Level, daher kann ich keine weiteren Details liefern.

Wenn Sie mutig sind, könnten Sie sogar ein Merge mit einer entpackten Datei durchführen. Es ist jedoch wahrscheinlich sicherer, sie als binär zu behandeln und ein externes Tool zu verwenden, um Diff und Merge durchzuführen. Verwenden Sie ein externes Tool für Diff und Merge.

Answer 4

Ich habe in den letzten Tagen mit genau diesem Problem gekämpft und ein kleines .NET-Dienstprogramm geschrieben, um Excel-Dateien zu extrahieren und zu normalisieren, sodass sie viel einfacher in der Versionskontrolle gespeichert werden können. Ich habe die ausführbare Datei hier veröffentlicht:

https://bitbucket.org/htilabs/ooxmlunpack/downloads/OoXmlUnpack.exe

..und den Quellcode hier:

https://bitbucket.org/htilabs/ooxmlunpack

Wenn Interesse besteht, bin ich gerne bereit, das Ganze konfigurierbarer zu machen. Aber im Moment sollten Sie die ausführbare Datei in einen Ordner (z.B. den Stamm Ihres Quellcode-Repositories) legen und wenn Sie sie ausführen, wird sie folgendes tun:

• Den Ordner und seine Unterordner nach .xlsx- und .xlsm-Dateien durchsuchen
• Eine Kopie der Datei als *.orig erstellen
• Jede Datei entpacken und neu komprimieren, ohne Kompression
• Alle Dateien im Archiv, die gültiges XML sind, schön formatieren
• Die calcchain.xml-Datei aus dem Archiv löschen (da sie sich oft ändert und den Inhalt der Datei nicht beeinflusst)
• Alle nicht formatierten Textwerte in Zeile einfügen (ansonsten werden sie in einer Lookup-Tabelle gespeichert, was zu großen Änderungen im internen XML führt, selbst wenn nur eine Zelle geändert wird)
• Die Werte aus Zellen löschen, die Formeln enthalten (da sie einfach berechnet werden können, wenn das Blatt beim nächsten Mal geöffnet wird)
• Einen Unterordner *.extracted erstellen, der den Inhalt des extrahierten Zip-Archivs enthält

Natürlich sind nicht alle diese Dinge notwendig, aber das Endergebnis ist eine Tabellendatei, die immer noch in Excel geöffnet werden kann, jedoch viel besser für das Vergleichen und inkrementelle Komprimierung geeignet ist. Außerdem macht es die Speicherung der extrahierten Dateien deutlicher, was in der Versionshistorie geändert wurde.

Wenn Bedarf besteht, bin ich bereit, das Tool konfigurierbarer zu machen, da wohl nicht jeder den Inhalt extrahiert haben möchte, oder möglicherweise die Werte aus den Formelzellen entfernt haben möchte, aber für mich sind beide Funktionen im Moment sehr nützlich.

In Tests wurde eine 2MB-Tabelle auf 21MB 'ausgepackt', danach konnte ich fünf Versionen davon mit kleinen Änderungen zwischen jeder in einer 1,9MB Mercurial-Datendatei speichern und die Unterschiede zwischen den Versionen effektiv mit Beyond Compare im Textmodus visualisieren.