5

With the October 2013 iWork update, the new UI is great but it seems one cannot store documents as 'flat file' any more. This really limits my ability to store the files, essentially ruling self-hosted version control (git, hg etc.) out of the picture.

The problem is:

  • adding a new picture to a document creates a new file within the bundle, which should be explicitly added to the version control

  • removing pictures removes them from the bundle but - again - version control should be notified.

I tried the trick of zipping the bundle and renaming it back to '.pages' (the way iWork'09 handled flat files) but it does not work.

Has anyone else been bit by this - do you have work-arounds (other than using iCloud, Dropbox - I'm fine with some of the documents living there but for some others I'd like to keep closer to my chest)?

Workarounds can be either on the iWork side, or ways that I get i.e. 'hg' (Mercurial) to version the bundle directories nicely.

Addendum

As the SO item says, I solved this by hg addremove. Other suggestions and discussion are still welcome. :)

  • There's a related discussion from the version control point of view here: stackoverflow.com/questions/27027/… – akauppi Nov 1 '13 at 13:42
  • 1
    Are there any specific reasons why you would not consider the built-in Versions feature of OS X and prefer Hg or Git? Seems like it would be simple to just manage it through OS X. – M K Nov 1 '13 at 17:37
  • 1
    I'm using Mercurial for software development and am just familiar with keeping files 'in the repo'. By 'Versions' you mean the OS X Time Machine feature, right? (deals with undoing changes but not in syncing files between computers). – akauppi Nov 1 '13 at 20:10
  • 1
    Plus, with packaged files, it seriously screws up when you try to sync with Dropbox and Google Drive! – Timothy Mueller-Harder Nov 16 '13 at 17:22
  • So, I presure (being the original author) that we're fine with not having an option but always storing stuff as 'bundles' (i.e. directories on the file system level). I was wrong - it just took a little time to find suitable ways to cope with it. – akauppi Nov 17 '13 at 18:26
1

The tool keynote-to-text gives a textual representation of a .key file. You can register it as the text converter for a Keynote file by adding to .gitconfig:

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

And .gitattributes:

*.key diff=keynote

Then git diff provides useful output:

  • Didn't know git can do such! There's many good answers to the question, depending on the needs of people. I haven't tested this one, but for elegance you get the Vote! – akauppi Apr 9 '14 at 14:45
0

Using git, I noticed that it just works as expected:

A git status gives me a handy list of the files to be added inside the presentation bundle.

With the shortcut git add -A you can add all of them in one go. I find this a very small inconvenience, if at all.

  • You are right. Also 'git commit -a' (if I recall right) does the same. – akauppi Nov 17 '13 at 18:23
  • 1
    True, but then in your git commit history you end up with a bunch of changes to a bunch of files that mean nothing to you — rather than an atomic change to the deck file, which is what you really want. – Avi Flax Dec 20 '13 at 15:14
0

Export to the prior format; it’ll be a flat file, not a package.

  • Theoretically, your suggestion would work, but the export would be needed to be repeated each time a file is changed (and it would slow down opening). Thus, I won't do so. I've grown to be okay with the directory-based new format. 'hg addremove' is enough to take the pain away from having .pages (or .numbers, .keynote) files in a repository. – akauppi Dec 21 '13 at 21:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .