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. :)

5
  • There's a related discussion from the version control point of view here: stackoverflow.com/questions/27027/…
    – akauppi
    Nov 1, 2013 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, 2013 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, 2013 at 20:10
  • 1
    Plus, with packaged files, it seriously screws up when you try to sync with Dropbox and Google Drive!
    – Tuesday
    Nov 16, 2013 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, 2013 at 18:26

3 Answers 3

2

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:

1
  • 1
    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, 2014 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.

2
  • You are right. Also 'git commit -a' (if I recall right) does the same.
    – akauppi
    Nov 17, 2013 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, 2013 at 15:14
0

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

1
  • 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, 2013 at 21:20

You must log in to answer this question.

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