Pro e contro per mantenere codice e dati in repository separati

Question

Abbiamo un progetto che contiene dati e codice, raggruppati in un unico repository Mercurial. I dati sono altrettanto importanti del codice (contiene parametri per la logica aziendale, alcuni input, ecc.) Tuttavia, il formato dei file di dati cambia raramente ed è abbastanza naturale modificare i file di dati indipendentemente dal codice.

Un vantaggio del repository unificato è che non dobbiamo tenere traccia di revisioni multiple: se abbiamo mai bisogno di ricreare l'output di una corsa precedente, abbiamo solo bisogno di aggiornare il sistema al numero di revisione singolo memorizzato in il registro di output.

Uno svantaggio è che se modifichiamo i dati mentre più teste sono attive, potremmo perdere le modifiche dei dati a meno che non copiamo manualmente tali modifiche su ciascuna testa.

Esistono altri vantaggi e svantaggi nella suddivisione del codice e dei dati in repository separati?

Answer 1

repos multipli:

• pro:

  • component-based approach (di identificare gruppi di file che possono evolvere in modo indipendente gli uni dagli altri)
  • specifica configurazione: si elenca i riferimenti (qui "revisioni") di cui hai bisogno per te r sistema per funzionare. Se si desidera modificare una parte senza modificare l'altra, si aggiorna quella lista.
  • cloni parziali: se non avete bisogno di tutti i componenti, è possibile clonare solo quelli che si desidera (non si applica nel tuo caso)

• contro

  • gestione della configurazione : è necessario tenere traccia di tale configurazione (di solito attraverso un repository padre, registrando subrepos)
  • nel tuo caso, i dati dipendono abbastanza da alcune versioni dei progetti (puoi avere nuovi dati che non hanno senso per il vecchio vers ioni del progetto)

---

Un pronti contro termine

• pro
  • system-based approach: vedete i moduli come un sistema (progetto e dei dati).gestione
  • pronti contro termine: tutto in uno
  • stretto collegamento tra i moduli (che può senso per i dati)
• contro
  • dati di propagazione (quando, come si parla, molti HEAD sono attivo)
  • revisioni intermedie (non per riflettere una nuova funzione, ma solo perché alcuni dati cambiano)
  • clone più grande (non rilevante qui, a meno che i dati comprendono grandi binari)

Per i dati non binari, con i cambiamenti frequenti, sarei ancora tenerli nello stesso repo.

Answer 2

Sì, è necessario separare il codice e i dati. Tieni il codice nel controllo della versione e i tuoi dati in un database.

Amo il controllo della versione poiché sono un programmatore da più di dieci anni e mi piace questo lavoro.

Ma negli ultimi mesi mi sono reso conto che: I dati non devono essere nel controllo di versione. A volte è difficile per una persona che ha familiarità con git (o un altro sistema di controllo della versione) a "lasciar perdere".

È necessario un buon ORM che supporti le migrazioni dello schema del database. Le migrazioni (schemamigrations e datamigrations) sono mantenute nel controllo della versione, ma i dati non lo sono.

So che la tua domanda riguardava l'utilizzo di uno o due repository, ma forse la mia risposta ti aiuta ad ottenere un diverso punto di vista.