Wie speichere ich neue iWork (2013) Dokumente in einer Flatfile (zur Versionskontrolle)?

Mit dem iWork-Update vom Oktober 2013 ist die neue Benutzeroberfläche großartig, aber es scheint, dass man Dokumente nicht mehr als „Flat File“ speichern kann. Dies schränkt meine Fähigkeit, die Dateien zu speichern, wirklich ein und schließt die selbst gehostete Versionskontrolle (git, hg usw.) im Wesentlichen aus dem Bild.

Das Problem ist:

  • Das Hinzufügen eines neuen Bildes zu einem Dokument erstellt eine neue Datei innerhalb des Bundles, die explizit der Versionskontrolle hinzugefügt werden sollte

  • Das Entfernen von Bildern entfernt sie aus dem Bundle, aber – auch hier – sollte die Versionskontrolle benachrichtigt werden.

Ich habe den Trick versucht, das Bündel zu komprimieren und es wieder in „.pages“ umzubenennen (wie iWork'09 flache Dateien handhabt), aber es funktioniert nicht.

Ist jemand anderes davon betroffen - haben Sie Problemumgehungen (außer der Verwendung von iCloud, Dropbox - ich bin mit einigen der dort gespeicherten Dokumente einverstanden, aber für einige andere möchte ich näher an meiner Brust bleiben)?

Problemumgehungen können entweder auf der iWork-Seite sein oder Möglichkeiten, wie ich zB 'hg' (Mercurial) bekomme, um die Bundle-Verzeichnisse gut zu versionieren.

Nachtrag

Wie der SO-Artikel sagt, habe ich das gelöst, indem ich hg addremove. Weitere Vorschläge und Diskussionen sind weiterhin willkommen. :)

Hier gibt es eine verwandte Diskussion aus Sicht der Versionskontrolle: stackoverflow.com/questions/27027/…
Gibt es bestimmte Gründe, warum Sie die integrierte Funktion von OS X nicht in Betracht Versionsziehen und Hg oder Git bevorzugen? Es scheint einfach zu sein, es einfach über OS X zu verwalten.
Ich verwende Mercurial für die Softwareentwicklung und bin nur damit vertraut, Dateien "im Repo" zu halten. Mit „Versionen“ meinen Sie die OS X Time Machine-Funktion, richtig? (befasst sich mit dem Rückgängigmachen von Änderungen, aber nicht mit dem Synchronisieren von Dateien zwischen Computern).
Außerdem wird es bei gepackten Dateien ernsthaft vermasselt, wenn Sie versuchen, mit Dropbox und Google Drive zu synchronisieren!
Daher betone ich (als Originalautor), dass wir damit einverstanden sind, keine Option zu haben, sondern Dinge immer als „Bündel“ (dh Verzeichnisse auf Dateisystemebene) zu speichern. Ich habe mich geirrt - es hat nur ein wenig gedauert, geeignete Wege zu finden, damit umzugehen.

Antworten (3)

Das Tool Keynote-to-Text gibt eine textuelle Darstellung einer .keyDatei. Sie können es als Textkonverter für eine Keynote-Datei registrieren, indem Sie Folgendes hinzufügen .gitconfig:

[diff "keynote"]
  binary = true
  textconv = /PATH/TO/KEYNOTE/keynote-to-text 

Und .gitattributes:

*.key diff=keynote

Dann git diffliefert nützliche Ausgabe:

Wusste nicht, dass Git so etwas kann! Es gibt viele gute Antworten auf die Frage, je nach den Bedürfnissen der Menschen. Ich habe es nicht getestet, aber für Eleganz bekommst du die Stimme!

Mit git habe ich festgestellt, dass es wie erwartet funktioniert:

A git statusgibt mir eine praktische Liste der Dateien, die dem Präsentationspaket hinzugefügt werden sollen.

Mit der Verknüpfung git add -Akönnen Sie alle auf einmal hinzufügen. Ich finde das eine sehr kleine Unannehmlichkeit, wenn überhaupt.

Du hast Recht. Auch 'git commit -a' (wenn ich mich recht erinnere) macht dasselbe.
Stimmt, aber dann landen Sie in Ihrem Git-Commit-Verlauf mit einer Reihe von Änderungen an einer Reihe von Dateien, die Ihnen nichts bedeuten – anstatt einer atomaren Änderung an der Deck-Datei, was Sie wirklich wollen.

Export in das vorherige Format; Es wird eine flache Datei sein, kein Paket.

Theoretisch würde Ihr Vorschlag funktionieren, aber der Export müsste jedes Mal wiederholt werden, wenn eine Datei geändert wird (und das Öffnen verlangsamen würde). Daher werde ich das nicht tun. Ich bin mittlerweile mit dem verzeichnisbasierten neuen Format einverstanden. 'hg addremove' reicht aus, um .pages (oder .numbers, .keynote) Dateien in einem Repository zu haben.