Flusso di lavoro: utilizzo di formati di documenti binari in Git senza blocchi (passaggio da subversion)

Question

Flusso di lavoro: utilizzo di formati di documenti binari in Git senza blocchi (passaggio da subversion)

#1 da (5 voti)
#2 da (2 voti)
#3 da (-1 voti)
#4 da (-2 voti)

16

Siamo una società di consulenza software con una moltitudine di progetti per diversi clienti. Usiamo tradizionalmente Subversion, ma al momento stiamo prendendo in considerazione il passaggio a Git.

Una parte significativa dei documenti che produciamo sono condivisi con i nostri clienti (requisiti, progetti globali, specifiche di prova, ecc.) e usiamo MS Office per produrli. In Subversion, potremmo usare la sua funzione "Lock" per garantire che nessuno stia modificando lo stesso documento allo stesso tempo. In Git, non puoi farlo poiché per la sua natura distribuita, git non ha lock.

I lucchetti sono davvero poco più di un meccanismo di comunicazione, ma sono molto efficaci.

Attualmente, il nostro codice e i documenti rivolti al cliente sono in genere in diverse sottocartelle di un repository svn diverso. Quando ti sposti, cosa consiglieresti di fare? Vedo un set di opzioni:

Spostiamo i repository svn su git 1-on-1. Invece di usare i blocchi sui file di Office, facciamo ciò che le persone git suggeriscono e in qualche modo proviamo a cambiare il nostro flusso di lavoro per risolverlo. Potrebbe funzionare in una succursale su qualsiasi modifica di un documento e unire quella sopra la revisione. Questo approccio si rompe ad es. Fogli Excel che contengono informazioni sulla gestione del progetto; sono facilmente modificati dai membri del team (e incoraggiamo a farlo), ma non sono soggetti ad alcun processo di revisione formale
Utilizziamo git per il codice e svn per i documenti e la gestione del progetto. Questo ha lo svantaggio che alcuni documenti di design più non saranno "vicini" al codice che specifica, aumentando la possibilità che le persone dimentichino di aggiornarli. Inoltre, tutti devono utilizzare e comprendere due set di strumenti. Detto questo, forse questa è una grande opportunità per passare a strumenti di documentazione basati su testo (latex, markdown, HTML, qualsiasi cosa) per documenti di progettazione non rivolti al cliente.
Mi piace 1, ma eseguiamo un comando git lock che fa ciò che svn lock fa per noi (imposta il flag di sola lettura in modo appropriato e sincronizza con un server in qualche modo).

Non compro l'argomento secondo cui i lock non funzionano in un DVCS perché il sistema dovrebbe funzionare anche quando sei completamente offline. Anche i blocchi Svn possono essere sovrascritti; sono un meccanismo di comunicazione . Senza un qualche tipo di connessione di rete, il tuo computer non comunicherà molto.

Non possiamo essere l'unico negozio che è molto contento di come svn lock si adatta al nostro flusso di lavoro, vero?

Qualche idea o suggerimento?

Ho trovato link ma la discussione è piuttosto tecnica ; Sto cercando modi per risolvere o evitare il problema pratico di due membri del team che modificano lo stesso file binario allo stesso tempo.

git svn dvcs excel word

posta skrebbel 22.01.2013 - 11:26

fonte

4 risposte

Leggi altre domande sui tag git svn dvcs excel word

Quali pratiche esistono per i test unitari specifici delle impostazioni locali? Con il senno di poi, basare XAML su XML è un errore o un buon approccio?

score 5 · Answer 1

Ti consiglierei di stare con SVN per i documenti di MS Office per due motivi:

È già lì ed è (secondo me) meglio da mantenere Documenti di Office (vedi qui ). Ha molti più strumenti di terze parti per farlo.
Il blocco, sebbene possa essere ottenuto in Git, non è "il modo Git del modo di fare le cose ". Se hai bisogno di queste funzionalità, segui lo strumento che ti dà la soluzione migliore.

C'è un detto che mi piace che dice qualcosa del tipo: "Quando hai in mano un martello, tutto sembra un chiodo". Solo perché ti stai trasferendo su Git per tenere il tuo codice, non significa che dovresti usarlo per conservare i tuoi documenti.

score 2 · Answer 2

Il controllo della versione del codice non è lo strumento migliore per lavorare sui file di Office, perché sono binari e questi strumenti funzionano con la modifica a livello di file.

Utilizza uno strumento di collaborazione, come MediaWiki (gratuito) o Atlassian Confluence (a pagamento), dal quale puoi facilmente estrarre il documento Word. Oppure usa LaTex per generare i file di Office.

Fammi espandere ...

Se hai bisogno di collaborare, devi adottare un modello che evidenzi le modifiche (ad esempio modificato una parola, riformulato o semplicemente modificato un carattere) in un'unità, ad es. un file.

SVN e Git, anche se pensati per il codice, sono strumenti di basso livello che confrontano i loro file con il contenuto testuale. Ma il problema è che possono lavorare solo su file di testo, perché non si preoccupano della natura / contenuto del file per estrarre un modello di modifiche di alto livello.

Un chiaro esempio è un file immagine . Anche se TortoiseMerge è uno strumento che aiuta gli utenti SVN confrontando le immagini per le loro reali modifiche, il normale VCS es viene eseguito dai contenuti patch sui file. Lasciatemi spiegare. Uno strumento come TortoiseMerge può dirti che una nuova versione di un file immagine viene modificata solo di pochi pixel, o luminanza se implementa un'analisi HSV più complessa dei due file. Puoi aggiungere una filigrana o cambiare i livelli di colore, uno strumento che confronta i file di immagine ti ti evidenzierà le differenze se implementa un buon algoritmo di confronto. Ma per verificare il nuovo file nel tuo cliente devi produrre un delta. Un delta è un insieme di linee che vengono rimosse e linee che vengono aggiunte al file. I file binari non hanno interruzioni di riga se non si verificano per avere \r\n , o simili, nel loro payload, e in un delta se si modifica un singolo carattere si sta sostituendo un'intera riga.

Quindi ecco il problema. I file binari non sono adatti al controllo della versione perché potresti quasi sostituire l'intero file per ogni revisione. Considera quando scrivi i file di Office usando MS Office e il tuo collaboratore modifica con OpenOffice. Se implementano anche una versione leggermente diversa dell'algoritmo di compressione dei file OpenXML, finirai con file completamente diversi anche se hai modificato una singola virgola nel documento.

I software di collaborazione rendono i documenti internamente in un formato basato sul testo, perché text è ciò che è veramente significativo per la tua azienda, e può calcolare le differenze o gestire i conflitti. LaTex o Markdown, se lo desideri, è un modo per archiviare un documento come file testuale con markup avanzato, quindi non come il classico file TXT che non ha controllo di font / formattazione.

Ma ovviamente ai tuoi clienti non piacerebbe aprire i file Markdown, vero? Ok, puoi semplicemente, e intendo semplicemente, utilizzare qualsiasi software per il quale sono attualmente troppo pigro per google al fine di convertire un documento sorgente in PDF, Word o altro.

Riassumendo

Se inizi a controllare i file di testo nel tuo controllo sorgente, hai un maggiore controllo sulla cronologia dei file e puoi gestire facilmente i conflitti, specialmente senza utilizzare i blocchi VCS.

Prima di condividere ufficialmente un documento è necessaria una routine per esportare il documento di testo di origine in un file di Office

Separare i due passaggi rende felici le persone a costo di una curva di apprendimento.

score -1 · Answer 3

Puoi usare git per quei documenti senza aggiungere il blocco. Scegli un flusso di lavoro git che blocchi i push al ramo master se non sul master. (Ci sono diversi flussi di lavoro tra cui scegliere.) Ciò impedirà alle persone di sovrascrivere le modifiche reciproche ai file di documenti binari. Supponiamo che due persone modifichino lo stesso documento binario. Il primo che lo spinge al master ottiene i loro cambiamenti. Il secondo verrà bloccato perché la loro copia è dietro il ramo principale. Devono prima sincronizzare. Quindi la seconda persona si sincronizza. Mostrerà un conflitto di unione per il documento binario. Quella persona salva la loro versione da qualche parte e risolve il conflitto prendendo la versione dal master (che è stata spinta dalla prima persona). A questo punto i file della seconda persona sono aggiornati con il ramo principale. Si uniscono nelle loro modifiche all'ultimo documento binario (a mano), che conterrà quindi le modifiche sia della prima persona sia della seconda persona. Quindi la nuova versione viene inviata al master e diventa il nuovo ramo principale. La fusione è un dolore, ma accade solo quando c'è un conflitto. Inoltre, le modifiche non vengono perse o sovrascritte. I conflitti vengono rilevati e gli utenti sono in grado di risolverli in modo pulito.

score -2 · Answer 4

Metti insieme le tue prime 2 soluzioni e non hai bisogno di un terzo.

Se salvi i fogli di lavoro su disco come CSV, Excel li modificherà e quindi git sarà lieto di unirli per te.

Allo stesso modo, puoi aprire, modificare e salvare i tuoi file in Word se sono in HTML o (dio ci aiuti) RTF. Ovviamente Word aggiungerà un testo più ingombrante del testo utile, ma è pur sempre un testo che git è felice di fondere per te.

Certo, queste soluzioni presumono che non si usi o si possa allontanarsi dalle funzionalità specifiche di MS, che in realtà è solo un problema sul lato Excel.

A meno che, naturalmente, non sia necessario installare Word su un sistema per poter leggere la documentazione, che è di per sé una prospettiva terrificante per me ...