Domanda

Qualcuno ha provato compresi i database di Visual FoxPro (ver 7) in SVN? Quali sono stati i vantaggi / svantaggi di includendolo nel? Qual è l'approccio migliore per gestire VFP Db in SCM, quando ci sono le righe che deve essere incluso nel controllo del codice sorgente?

Nessuna soluzione corretta

Altri suggerimenti

Christof Wollenhaupt ha uno strumento chiamato "TwoFox" che fa un buon lavoro di conversione DBCs e altri file di origine Fox a XML - l'articolo che descrive è http://www.foxpert.com/docs/cvs.en.htm . Se si sta solo chiedendo di far cadere i file DBF in SVN, però, è possibile importarli come file binari, e perdono la capacità di confronto / unione tra le versioni, o utilizzare CURSORTOXML (che era in 7, non è vero?) per convertire i DBF in XML prima di check-in.

Mentre non ho usato SVN, ho usato VFP sia con VSS e Vault. Con entrambi questi, aggiungo manualmente i file al controllo del codice sorgente, piuttosto che cercare di utilizzare una qualche forma di integrazione all'interno dell'ambiente Dev.

Ci sono fondamentalmente due modi si potrebbe avvicinarsi a questo:

  1. Basta aggiungere manualmente il DBC, .DCT, .DCX e tutto il .DBF, .FPT e .CDX
  2. Scrivi uno script dal database per creare la struttura (io uso una versione modificata di GenDBCX), e la creazione di script di tutti i record di dati che si desidera conservare su un programma o di classe.

La mia configurazione:



  • Debian su una workstation P4, in esecuzione:
    • Subverison tramite Apache2
    • Trac con ganci in Subversion
    • backup notturni regolari sia Subversion e il database Trac

Francamente, non controlli nei database multi-megabyte che abbiamo perché il repository sarebbe gonfiare a circa 20 + Gbyte nel formato da che da soli. Abbiamo regolarmente tabelle 1,6 GB (e le loro note e indici) ed è semplicemente non vale la pena di ore sprecate in attesa di un 1 ora-plus impegnarsi su 20Gbytes di modifiche della tabella. Invece, cloniamo i dati dal nostro sistema di produzione e l'uso che per "rinfrescare" le cose, e ricostruire il nostro contenitore database per avere collegamenti freschi ai tavoli. Il processo di "aggiornamento" è fatto circa una volta al mese e richiede molto meno tempo, di solito 40 minuti; Questo contrasto con ore di sprecare ogni giorno .

Non ho avuto la necessità di controllare nei dati nel repository, anche una sola volta. Gestione dello schema è stata semplificata, seguendo una sola regola per il momento: aggiornare i dati solo dopo che tutte le patch significato per la produzione sono stati spinti in produzione, che implica lo schema per entrambi gli ambienti sarà coerente. Per ora, posso farla franca con questo, anche se questo dovrà cambiare in futuro ...

Se avete solo bisogno modifiche dello schema

Se si scopre che si ha bisogno per il check-in tabelle perché si sta cercando di catturare la loro dello schema e non necessariamente le Dati che contengono, si potrebbe desiderare di guardare scrittura di un piccolo strumento che eroga lo schema in un file di testo e commettere che al pronti contro termine, invece di spedire il lavello della cucina fuori per essere digerito.

Se è assolutamente necessario verificare nei dati

Se ci sono dati nelle tabelle che è fondamentale per controllare il flusso del programma (-as-codice dati, e non solo i dati che viene elaborato dal programma), si potrebbe considerare il taglio dei dati al minimo richiesto e il check-in solo i tavoli stub risultanti con l'aggiunta manualmente al repo. Mentre la sovversione gestirà oggetti binari, si vorrà mantenere questi per una dimensione minima e commetterli il meno possibile in modo che il repo non impantanarsi. Assicuratevi di controllare nelle singole tabelle che stai dopo, e non solo tutti * .dbf, o si può essere uno shock scortese quando qualcun altro cerca di spingere diversi gigabyte di dati nel pronti contro termine, perché la copia di lavoro non lo fa mascherare tutte le tabelle.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top