Modo preferito per inserire i disegni nel repository Git

4

Per visualizzare alcuni concetti in un repository Git per altri sviluppatori, Voglio mettere lì alcuni disegni vettoriali. Ovviamente non dovrebbero essere binari. Se si verificano cambiamenti minori, anche la modifica del file dovrebbe essere minima. Fino a questo punto penso al formato flat XML odf . È una buona idea?

    
posta mcocdawc 06.05.2017 - 15:46
fonte

2 risposte

7

Per la grafica vettoriale generica , SVG è la strada da percorrere.

Per ulteriori usi specifici , a volte sono disponibili lingue più specifiche. Ad esempio, OMG specifica una rappresentazione XML completa per UML, quindi se la grafica vettoriale è in realtà diagrammi UML, è possibile utilizzarla al suo posto. Oppure, ancora meglio, ci sono vari linguaggi in chiaro per determinati sottoinsiemi di certi diagrammi UML, per esempio PlantUML o yUML (Nota: yUML è un servizio web che codifica la descrizione in chiaro del diagramma nell'URI e restituisce un grafico, non è quello che vuoi, ma il linguaggio usato da yUML potrebbe essere riutilizzato anche all'interno dei file di testo.) Controlla questo elenco di lingue UML testuali .

Per i grafici, esiste la potente e venerabile DOT lingua. Molti strumenti comprendono DOT, l'implementazione originale è GraphViz .

Il servizio web DiagrammR non esiste più, ma la libreria è ancora su GitHub.

In generale, ci sono due approcci:

  • descrive il diagramma su un livello superiore, quindi genera un grafico da quella descrizione
  • disegna il diagramma come ASCII-art, quindi converti l'arte ASCII in un modulo grafico

Probabilmente vuoi il primo, non il secondo. L'unico vantaggio che quest'ultimo ha sui file binari è che puoi guardarli in un editor di testo. Ma la fusione e la diffusione probabilmente saranno altrettanto inutili, dal momento che tutti questi strumenti sono basati sulla linea e l'arte ASCII è bidimensionale. I primi sono più simili ai linguaggi di programmazione: un concetto == una riga.

If minor changes occur, the file change should be minor as well.

Git memorizza sempre in modo logico un'istantanea dell'intero file per revisione, indipendentemente dal fatto che il file sia binario o di testo. (In effetti, a Git non interessa affatto il contenuto dei file, quindi il concetto stesso di "testo" o "binario" è fondamentalmente privo di significato.)

Il formato di archiviazione fisico sono i cosiddetti "file pack". Nei file pack, il intero repository (cioè tutti file dalle tutte revisioni) sono concatenati in un singolo file e la compressione delta viene applicata a il pacchetto intero , ovvero Git (in modo intelligente) cerca le somiglianze nelle diverse revisioni dello stesso file, diversi file nella stessa revisione, diversi file attraverso revisioni diverse e praticamente ovunque, e comprime efficientemente quelli .

Ancora una volta, non importa se il file è binario o di testo. È che importa se si utilizza un formato in cui piccole modifiche al contenuto astratto portano a grandi cambiamenti nel flusso di byte serializzato. Che sarebbe effettivamente inefficiente. Un esempio (immaginario) sarebbe un file PDF: i file PDF di solito contengono contenuti compressi, ma non devono, e in Git, sarebbe effettivamente più efficiente in termini di spazio per utilizzare PDF non compressi, perché quindi il packer potrebbe rilevare il somiglianze tra due revisioni. Mentre quando il contenuto viene compresso, il file compresso spesso appare completamente diverso anche se ci sono solo piccole modifiche al contenuto effettivo.

    
risposta data 06.05.2017 - 18:07
fonte
2

Il formato SVG è un formato vettoriale ben noto e ampiamente accettato. È basato su XML, quindi è Git friendly. SVG è uno standard aperto supportato dal consorzio W3C.

SVG soddisfa i criteri necessari.

    
risposta data 06.05.2017 - 16:28
fonte

Leggi altre domande sui tag