File zippati controllanti la versione (docx, odt)

Question

Esistono formati che sono in realtà file zip nascosti, ad es. docx o odt. Se li memorizzo direttamente nel controllo di versione, vengono gestiti come file binari. La mia soluzione ideale sarebbe

• avere un gancio che crea una directory foo.docx/ per ogni foo.docx file prima di commettere, decomprimere tutti i file in esso
• opzionalmente, un gancio che reindents i file XML
• hanno un gancio ricreare foo.docx dai file memorizzati dopo l'aggiornamento

Non voglio che i file docx siano controllati dalla versione. (Sono a conoscenza di un related question in cui è stato suggerito un approccio diverso con una diff personalizzata.)

È fattibile? È fattibile con mercurio?

UPDATE:

so di ganci. Sono interessato allo specifico. Ecco una sessione per dimostrare il comportamento previsto.

> 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

Se riesci a superare l'ostacolo di decomprimere con successo e zippare i documenti di Openoffice, dovresti essere in grado di utilizzare lo filter system che abbiamo in Mercurial. Ciò consente di trasformare i file su ogni lettura/scrittura da/verso il repository.

Si dovrà sfortunatamente fare molto di più che decomprimere il file foo.docx. Il problema è che devi generare un singolo file come output, quindi forse puoi unzip foo.docx e poi tar i file generati. Quindi eseguirai il versioning del tarball, che dovrebbe funzionare poiché un tarball non è altro che una concatenazione non compressa di tutti i singoli file con alcune meta informazioni. Vieni a pensarci, una soluzione più semplice sarebbe quella di comprimere nuovamente il file foo.docx decompresso ma non specificare alcuna compressione. Questo dovrebbe dare risultati simili a quelli dell'utilizzo di tar.

Risolvere questo problema è qualcosa che volevo fare da solo, quindi segnalarlo inviando una mail allo Mercurial mailing list.

Answer 2

È possibile utilizzare un gancio precommit per decomprimere, e un gancio aggiornamento di zip. Vedi the definite guide su come usare i ganci.

Fare attenzione alla rinomina. Se si rinomina foo.docx in bar.docx, il gancio di precommit dovrà eliminare foo.docx/ e aggiungere bar.docx/.

---

UPDATE (spiacente per dare una risposta entry-level a un utente 1k-rep)

Se si desidera utilizzare docx spacchettato per le operazioni di base HG come diff (status può lavorare con file compresso), dovresti andare con un'estensione. Penso che si possa adottare un approccio simile a quello keyword extension in modo da racchiudere l'oggetto Repo con il proprio.

Ho scritto alcune estensioni ma non a quel livello di base, quindi non posso fornire ulteriori dettagli.

Se si vuole impazzire si potrebbe anche unire con un file decompresso. Ma probabilmente è più sicuro trattarlo come binario e use external tool da diff e unire.

Answer 3

Mi stavo chiedendo la stessa cosa e ho appena trovato l'estensione/filtro ZipDoc per Mercurial, che sembra fare esattamente questo!

Non ho ancora provato, ma sembra promettente!

Answer 4

Sono stato alle prese con questo problema esatto negli ultimi giorni e ho scritto una piccola utility .NET per estrarre e normalizzare i file di Excel in modo tale che siano molto più facili da memorizzare nel controllo del codice sorgente. Ho pubblicato l'eseguibile qui:

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

..e la fonte qui:

https://bitbucket.org/htilabs/ooxmlunpack

Se c'è qualche interesse sono felice di fare questo più configurabile, ma al momento, dovresti inserire l'eseguibile in una cartella (es. la radice del tuo repository sorgente) e quando lo esegui, lo farà:

• der e le sue sottocartelle per qualsiasi .xlsx e un file xlsm
• Prendere una copia del file come * .orig
• Unzip ogni file e ri-Zip con nessuna compressione
• Pretty-stampa tutti i file nell'archivio che sono validi XML
• Elimina il file calcchain.xml dall'archivio (poiché cambia molto e non influisce sul contenuto del file)
• Inline qualsiasi valore di testo non formattato (altrimenti vengono mantenuti in una tabella di ricerca che causa grandi cambiamenti nell'XML interno se anche una singola cella viene modificata)
• Elimina i valori da qualsiasi cellule che contengono formule (in quanto possono essere calcolati solo quando il foglio viene successivamente aperto)
• creare una sottocartella * .extracted, contenente i contenuti dell'archivio zip estratti

Chiaramente non tutte queste cose sono necessarie, ma il risultato finale è un file di foglio di calcolo che verrà ancora aperto in Excel ma che è molto più suscettibile alla compressione differenziale e incrementale. Inoltre, anche la memorizzazione dei file estratti rende molto più evidente nella cronologia delle versioni quali modifiche sono state applicate in ciascuna versione.

Se c'è qualche appetito là fuori, sono felice di rendere lo strumento più configurabile in quanto credo che non tutti vorranno i contenuti estratti, o, eventualmente, i valori rimossi dalle celle delle formule, ma questi sono entrambi molto utile per me il momento.

In test, un foglio di calcolo di 2MB "scompatta" a 21MB ma poi sono riuscito a memorizzare cinque versioni di esso con piccole modifiche tra ognuna, in un file di dati mercurial da 1,9 MB, e visualizzare le differenze tra le versioni utilizzando in modo efficace Beyond Compare in modalità testo.