¿Cómo almacenar documentos nuevos de iWork (2013) en un archivo plano (para control de versiones)?

Con la actualización de iWork de octubre de 2013, la nueva interfaz de usuario es excelente, pero parece que ya no se pueden almacenar documentos como "archivos planos". Esto realmente limita mi capacidad para almacenar los archivos, esencialmente eliminando el control de versiones alojado en mí mismo (git, hg, etc.).

El problema es:

  • agregar una nueva imagen a un documento crea un nuevo archivo dentro del paquete, que debe agregarse explícitamente al control de versión

  • eliminar imágenes las elimina del paquete pero, nuevamente, se debe notificar al control de versiones.

Intenté el truco de comprimir el paquete y cambiarle el nombre a '.pages' (la forma en que iWork'09 manejó los archivos planos), pero no funcionó.

¿Alguien más ha sido mordido por esto? ¿Tiene soluciones alternativas (aparte de usar iCloud, Dropbox; estoy bien con algunos de los documentos que viven allí, pero para algunos otros me gustaría mantenerlos más cerca de mi cofre)?

Las soluciones alternativas pueden estar en el lado de iWork o en formas en las que obtengo, por ejemplo, 'hg' (Mercurial) para versionar bien los directorios del paquete.

Apéndice

Como dice el elemento SO, resolví esto por hg addremove. Otras sugerencias y debates siguen siendo bienvenidos. :)

Hay una discusión relacionada desde el punto de vista del control de versiones aquí: stackoverflow.com/questions/27027/…
¿Hay alguna razón específica por la que no consideraría la Versionsfunción integrada de OS X y preferiría Hg o Git? Parece que sería simple administrarlo a través de OS X.
Estoy usando Mercurial para el desarrollo de software y estoy familiarizado con mantener archivos 'en el repositorio'. Por 'Versiones' te refieres a la característica de OS X Time Machine, ¿verdad? (se ocupa de deshacer cambios pero no de sincronizar archivos entre computadoras).
Además, con los archivos empaquetados, ¡se complica mucho cuando intentas sincronizar con Dropbox y Google Drive!
Por lo tanto, asumo (siendo el autor original) que estamos bien con no tener una opción pero siempre almacenando cosas como 'paquetes' (es decir, directorios en el nivel del sistema de archivos). Me equivoqué, solo me tomó un poco de tiempo encontrar formas adecuadas de lidiar con eso.

Respuestas (3)

La herramienta keynote-to-text ofrece una representación textual de un .keyarchivo. Puede registrarlo como convertidor de texto para un archivo de Keynote agregando a .gitconfig:

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

y .gitattributes:

*.key diff=keynote

Luego git diffproporciona una salida útil:

¡No sabía que git podía hacer eso! Hay muchas buenas respuestas a la pregunta, dependiendo de las necesidades de las personas. ¡No he probado este, pero por elegancia obtienes el voto!

Usando git, noté que funciona como se esperaba:

A git statusme da una lista útil de los archivos que se agregarán dentro del paquete de presentación.

Con el atajo git add -Apuedes agregarlos todos de una sola vez. Creo que esto es un inconveniente muy pequeño, en todo caso.

Tienes razón. También 'git commit -a' (si no recuerdo mal) hace lo mismo.
Cierto, pero luego, en su historial de confirmación de git, termina con un montón de cambios en un montón de archivos que no significan nada para usted, en lugar de un cambio atómico en el archivo de plataforma, que es lo que realmente desea.

Exportar al formato anterior; será un archivo plano, no un paquete.

Teóricamente, su sugerencia funcionaría, pero sería necesario repetir la exportación cada vez que se cambie un archivo (y ralentizaría la apertura). Por lo tanto, no lo haré. He llegado a estar de acuerdo con el nuevo formato basado en directorios. 'hg addremove' es suficiente para aliviar el dolor de tener archivos .pages (o .numbers, .keynote) en un repositorio.
¿Cómo almacenar documentos nuevos de iWork (2013) en un archivo plano (para control de versiones)?
RespuestasAquíPolítica de privacidad1y, 0v