Domanda File zippati controllanti la versione (docx, odt)


Esistono formati che sono in realtà file zip sotto mentite spoglie, 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 un foo.docx/ directory per ciascuno foo.docx file prima di eseguire il commit, decomprimendo tutti i file in esso contenuti
  • opzionalmente, avere un hook che rientri i file xml
  • avere un gancio che ricrea foo.docx dai file memorizzati dopo l'aggiornamento

Non voglio che i file docx siano controllati dalla versione. (Sono consapevole di a domanda correlata dove è stato suggerito un approccio diverso con una diff personalizzata).

È fattibile? È fattibile con mercurio?

AGGIORNARE:

Conosco gli ami. 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>

19
2017-09-21 22:41


origine


risposte:


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

Dovrai sfortunatamente fare molto di più che decomprimere il file foo.docx. Il problema è che devi generare un singolo file come output, quindi forse puoi farlo 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 segnalalo inviando una mail a Mailing list Mercurial.


5
2017-09-24 11:23



Mi stavo chiedendo la stessa cosa, e mi sono appena imbattuto nel ZipDoc estensione / filtro per Mercurial, che sembra fare esattamente questo!

Non l'ho ancora provato, ma sembra promettente!


13
2018-06-17 12:08



È possibile utilizzare un hook precommit per decomprimere e un hook di aggiornamento per comprimere. Vedere la guida definitiva su come usare i ganci.

Fai attenzione a rinominare. Se si rinomina foo.docx a bar.docx, il tuo hook precommit dovrà essere cancellato foo.docx/ e aggiungi bar.docx/.


AGGIORNAMENTO (mi dispiace per aver dato una risposta entry-level a un utente 1k-rep)

Se si desidera utilizzare docx decompresso per le operazioni di core hg come diff (status può funzionare con file compresso), dovresti andare con un'estensione. Penso che tu possa adottare un approccio simile a quello di keyword estensione come avvolgere l'oggetto Repo con il tuo.

Ho scritto alcune estensioni ma non a quel livello così difficile, quindi non posso fornire ulteriori dettagli.

Se vuoi diventare pazzo potresti persino unirmi con un file decompresso. Ma probabilmente è più sicuro trattarlo come binario e utilizzare uno strumento esterno diff e unire.


3
2017-09-22 01:24



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 renderlo più configurabile, ma al momento, dovresti mettere l'eseguibile in una cartella (ad esempio la radice del tuo repository sorgente) e quando lo esegui, lo farà:

  • Analizza la cartella e le relative sottocartelle per qualsiasi file .xlsx e .xlsm
  • Prendi una copia del file come * .orig
  • Decomprimere ogni file e ricollegarlo senza compressione
  • Pretty-stampa tutti i file nell'archivio che sono XML validi
  • Elimina il file calcchain.xml dall'archivio (poiché cambia molto e non influisce sul contenuto del file)
  • Inline tutti i valori 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 cella che contiene formule (poiché possono essere calcolate solo quando il foglio viene aperto successivamente)
  • Crea una sottocartella * .estratta, contenente il contenuto dell'archivio zip estratto

Chiaramente non tutte queste cose sono necessarie, ma il risultato finale è un file di foglio di calcolo che verrà comunque 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'è appetito là fuori, sono felice di rendere lo strumento più configurabile dal momento che immagino che non tutti vorranno il contenuto estratto, o forse i valori rimossi dalle celle della formula, ma sono entrambi molto utili per me al momento.

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


0
2018-06-10 15:33