Perché i sistemi di controllo del codice sorgente sono ancora per lo più supportati da file?

22

Sembra che più sistemi di controllo del codice sorgente utilizzino ancora i file come mezzo per archiviare i dati della versione. Vault e TFS utilizzano Sql Server come archivio dati, che riterrei migliore per coerenza dei dati e velocità.

Quindi perché SVN, credo che GIT, CVS, ecc. Utilizzino ancora il file system essenzialmente come un database (faccio questa domanda poiché il nostro server SVN si è appena corrotto durante un normale commit) invece di utilizzare un vero software di database ( MSSQL, Oracle, Postgre, ecc.)?

EDIT: Penso che un altro modo di porre la mia domanda sia "perché gli sviluppatori VCS eseguono il rollup del proprio sistema strutturato di archiviazione dei dati invece di usarne uno esistente?"

version-control

— Andy
fonte

29

Cosa pensi che la maggior parte dei database utilizzi come supporto di base? La maggior parte usa i file (alcuni usano l'accesso diretto ai dischi rigidi, tuttavia). Puoi avere tutte le funzionalità di un database usando "solo file".

— Joachim Sauer,

2

@JoachimSauer Fair point, anche se ovviamente dovresti creare un database tu stesso. Il che è sciocco se il set di funzionalità desiderato è vicino a quello delle soluzioni esistenti e non ha ottime ragioni per non usarne nessuna.

1

@JoachimSauer Sì, me ne rendo conto, ma i sistemi DBM hanno dei modi per garantire che nulla di incoerente entri nel database. A meno che questi repository basati su file non utilizzino qualcosa come Transactional NTSF, c'è ancora la possibilità di essere corrotti. E mi fido di un vero database più di quanto non faccia un set di sviluppatori che reinventa essenzialmente la ruota, dal momento che penso che possiamo essere d'accordo sul fatto che i sistemi di controllo del codice sorgente richiedono l'integrità dei dati.

— Andy,

2

@delnan Supporto transazionale e coerenza interna. Ora stiamo ripristinando il nostro repository SVN dal nastro b / c che il server SVN non ha scritto correttamente su tutti i file che doveva. Cerca anche enormi volumi di dati. Il mio punto è, perché provare a reinventare la ruota.

— Andy,

7

Tutti i principali sistemi operativi sono dotati di un file system integrato. Tutti questi file system hanno le stesse funzionalità di base (file, cartelle, persistenza dello stesso). Fondamentalmente, un database è una dipendenza aggiuntiva che l'utente finale deve installare e mantenere aggiornato. Il controllo del codice sorgente non è l'attività principale della maggior parte delle persone (a meno che tu non sia sourceforge o github). VC viene spesso installato sui server tramite la riga di comando dal nuovo membro del team. La facilità di installazione e configurazione è importante.

— GlenPeterson,

23

TL; DR: pochi sistemi di controllo della versione utilizzano un database perché non è necessario.

Come domanda per una risposta a una domanda, perché non dovrebbero? Quali vantaggi offrono i sistemi di database "reali" rispetto a un file system in questo contesto?

Considera che il controllo di revisione sta principalmente tenendo traccia di piccoli metadati e molte differenze di testo. Il testo non viene archiviato nei database in modo più efficiente e l'indicizzazione dei contenuti non sarà un fattore.

Supponiamo che Git (per l'argomento) abbia usato un BDB o un DB SQLite come back-end per archiviare i dati. Cosa sarebbe più affidabile al riguardo? Tutto ciò che potrebbe danneggiare file semplici può anche corrompere il database (poiché si tratta anche di un file semplice con una codifica più complessa).

Dal paradigma del programmatore di non ottimizzare a meno che non sia necessario, se il sistema di controllo delle revisioni è abbastanza veloce e funziona in modo abbastanza affidabile, perché cambiare l'intero progetto per utilizzare un sistema più complesso?

— mikebabcock
fonte

2

TLDR? La tua risposta era lunga il doppio e la domanda era davvero breve!

— Brad,

25

@Brad Le tre parole che seguono TL;DRsono la versione ridotta delle risposte, non un'affermazione secondo cui la domanda è troppo lunga e non l'ha letta prima di rispondere.

6

@Andy Mercurial ha anche "grep nella storia", e probabilmente anche git ce l'ha. Inoltre è già velocissimo. Per quanto riguarda il lasciare le cose agli esperti: le persone che sviluppano i VCS sono esperti.

3

Voglio solo aggiungere che vedo il tuo punto; se VCS scrive dati errati, non importa se sta scrivendo quei dati in un file o database. Il rovescio della medaglia però è che i repository basati su file probabilmente stanno scrivendo su più di un file alla volta e normalmente non c'è supporto transazionale per questo, quindi se un file scrive ma un altro fallisce, il tuo VCS ora è corrotto, mentre la tabella multipla scrive all'interno di un database la transazione commetterà per errore come unità. Sento che un gruppo di sviluppatori che sviluppano software per database ha più esperienza con questo rispetto alle persone che scrivono SVN ... ma forse mi sbaglio.

— Andy,

6

La tua scelta di git "per l'argomento" è un punto importante qui: git ha un ottimo modello per scrivere i suoi oggetti, ma molti strumenti no. Con git, se il computer è spento nel bel mezzo di un commit, avrai scritto alcuni degli oggetti nel filesystem e saranno semplicemente irraggiungibili. Con altri VCS, potresti aver aggiunto le modifiche a metà dei file (e ne consegue la confusione). Potresti sostenere che altri strumenti di controllo della versione sono mal progettati (e avresti ragione), ma quando scrivi un VCS, è molto più semplice usare una transazione SQL e lasciarlo fare la cosa giusta.

— Edward Thomson,

25

Sembra che tu stia facendo molte ipotesi, probabilmente sulla base della tua esperienza con SVN e CVS.

Git e Mercurial sono fondamentalmente come SVN e CVS

Confrontare git e CVS è come confrontare un iPad e un Atari. CVS è stato creato quando i dinosauri vagavano per la Terra . Subversion è sostanzialmente una versione migliorata di CVS. Supponendo che i moderni sistemi di controllo delle versioni come git e Mercurial funzionino come loro, ha poco senso.

Un database relazionale è più efficiente di un database monouso

Perché? I database relazionali sono davvero complicati e potrebbero non essere efficienti come i database monouso. Alcune differenze dalla parte superiore della mia testa:

I sistemi di controllo della versione non richiedono un blocco complicato, poiché non è possibile eseguire più commit contemporaneamente allo stesso tempo.
I sistemi di controllo della versione distribuita devono essere estremamente efficienti in termini di spazio, poiché il database locale è una copia completa del repository.
I sistemi di controllo della versione devono solo cercare i dati in un paio di modi specifici (per autore, per ID di revisione, a volte ricerca full-text). Creare il proprio database in grado di gestire ricerche di ID autore / revisione è banale e le ricerche full-text non sono molto veloci in nessun database relazionale che ho provato.
I sistemi di controllo della versione devono funzionare su più piattaforme. Ciò rende più difficile l'uso di un database che deve essere installato ed eseguito come servizio (come MySQL o PostgreSQL).
I sistemi di controllo della versione sul tuo computer locale devono essere in esecuzione solo quando stai facendo qualcosa (come un commit). Lasciando un servizio come MySQL in esecuzione tutto il tempo nel caso in cui si vuole fare un commit è uno spreco.
Per la maggior parte, i sistemi di controllo della versione non vogliono mai eliminare la cronologia, basta accedervi. Ciò può comportare diverse ottimizzazioni e diversi metodi di protezione dell'integrità.

I database relazionali sono più sicuri

Ancora una volta, perché? Sembri presumere che, poiché i dati sono archiviati in file, i sistemi di controllo della versione come git e Mercurial non hanno commit atomici , ma lo fanno. I database relazionali memorizzano anche i loro database come file. È degno di nota qui che CVS non esegue commit atomici, ma è probabile perché proviene dai secoli bui, non perché non usano database relazionali.

C'è anche il problema di proteggere i dati dalla corruzione una volta che sono nel database, e di nuovo la risposta è la stessa. Se il filesystem è corrotto, non importa quale database stai usando. Se il filesystem non è danneggiato, il tuo motore di database potrebbe essere danneggiato. Non vedo perché un database di controllo versione sarebbe più incline a questo di un database relazionale.

Direi che i sistemi di controllo della versione distribuita (come git e Mercurial) sono migliori per proteggere il tuo database rispetto al controllo centralizzato della versione, poiché puoi ripristinare l'intero repository da qualsiasi clone. Quindi, se il tuo server centrale combina spontaneamente, insieme a tutti i tuoi backup, puoi ripristinarlo eseguendolo git initsul nuovo server, quindi git pushda qualsiasi macchina dello sviluppatore .

Reinventare la ruota è male

Solo perché puoi utilizzare un database relazionale per qualsiasi problema di archiviazione non significa che dovresti . Perché usi i file di configurazione anziché un database relazionale? Perché archiviare immagini sul filesystem quando è possibile archiviare i dati in un database relazionale? Perché conservare il codice sul filesystem quando è possibile archiviarlo tutto in un database relazionale?

"Se tutto ciò che hai è un martello, tutto sembra un chiodo."

C'è anche il fatto che i progetti open source possono permettersi di reinventare la ruota ogni volta che è conveniente, dal momento che non hai gli stessi tipi di vincoli di risorse dei progetti commerciali. Se hai un volontario esperto nella scrittura di database, perché non usarli?

Per quanto riguarda il motivo per cui dovremmo fidarci degli autori dei sistemi di controllo delle revisioni per sapere cosa stanno facendo .. Non posso parlare per altri VCS, ma sono abbastanza sicuro che Linus Torvalds capisca i filesystem .

Perché alcuni sistemi di controllo delle versioni commerciali utilizzano un database relazionale?

Molto probabilmente una combinazione dei seguenti:

Alcuni sviluppatori non vogliono scrivere database.
Gli sviluppatori di sistemi di controllo delle versioni commerciali hanno vincoli di tempo e risorse, quindi non possono permettersi di scrivere un database quando hanno qualcosa di simile a ciò che desiderano già. Inoltre, gli sviluppatori sono costosi e gli sviluppatori di database (come in, le persone che scrivono database) sono probabilmente più costosi, poiché la maggior parte delle persone non ha quel tipo di esperienza.
Gli utenti dei sistemi di controllo della versione commerciale hanno meno probabilità di preoccuparsi del sovraccarico di impostazione e gestione di un database relazionale, poiché ne hanno già uno.
È più probabile che gli utenti dei sistemi di controllo delle versioni commerciali desiderino che un database relazionale supporti i propri dati di revisione, poiché ciò potrebbe integrarsi meglio con i loro processi (come ad esempio i backup).

— Ripristina Monica
fonte

1

Una cosa: i commit SVN sono atomici. In effetti, è un importante punto di forza (o almeno lo era, quando dovevano convincere gli utenti CSV a passare).

1

@delnan - Nota che c'è una grande differenza tra l' atomicità teorica che ottieni con le svndiverse directory nella tua directory di lavoro che possono trovarsi a diverse svnrevisioni e l'atomicità ampia del vero repository che ottieni con gito hg.

— Mark Booth,

2

@Andy E il mio punto è che puoi gestire quegli stessi scenari esatti senza un database relazionale completo. Se due persone si impegnano contemporaneamente, il server può fare uno dopo l'altro. Non è una funzionalità complicata da implementare. Se vuoi farlo con un utente locale, basta avere un file di blocco. Quando si avvia un commit, ottenere un blocco sul file. Quando si termina un commit, rilasciare il blocco. Se si desidera consentire il commit su più rami contemporaneamente, utilizzare un file di blocco per ciascun ramo. Certo, SQLite lo farebbe per me, ma non è necessario .

— Ripristina Monica il

1

Allo stesso modo, l'implementazione di un journal di base non è complicata. (1) Scrivi il nuovo commit in un file. (2) Copia il vecchio file indice. (3) Scrivi un nuovo file indice. (4) Elimina la copia del vecchio file indice. Se fallisci al passaggio 1, 2 o 4, devi solo ripulire i nuovi file che hai creato. In caso di errore al passaggio 3, è sufficiente copiare nuovamente il vecchio file indice. Qualcuno che capisce meglio i filesystem potrebbe probabilmente renderne una versione molto più efficiente, ma puoi sempre fare riferimento al codice sorgente di SQLite se necessario (è di dominio pubblico).

— Ripristina Monica il

1

@BrendanLong Ottimi punti. Apprezzo la discussione. Giusto per essere chiari, penso che ci siano vantaggi e svantaggi per entrambi i tipi di negozi di supporto, non credo che ci sia una sola risposta corretta. Comunque sono rimasto un po 'sorpreso, sembra che ce ne siano solo tre (quattro se conti separatamente Vault e Vercity) che usano SQL e la stragrande maggioranza no, tutto qui.

— Andy,

18

svnUtilizzato effettivamente per utilizzare BDB per i repository. Questo alla fine è stato eliminato perché era soggetto a rotture.

Un altro VCS che attualmente utilizza un DB (SQLite) è fossil. Integra anche un bug tracker.

La mia ipotesi sul vero motivo è che i VCS funzionano con molti file. I filesystem sono solo un altro tipo di database (gerarchico, focalizzato sull'efficienza dello storage CLOB / BLOB). I database normali non gestiscono così bene perché non c'è motivo di - i filesystem esistono già.

— Mike Larsen
fonte

1

BDB non conta esattamente come affidabile - come SQLite è un database in-process. Detto questo, penso che l'affidabilità di Oracle / MSSQL / MySQL / Postgres, a seconda di come li configuri, non è molto diversa dai filesystem. Il problema principale è che gli RDBMS non sono creati per le strutture gerarchiche e grafiche con cui normalmente lavorano i VCS. E in quel caso, i filesystem vincono e basta.

— Mike Larsen,

3

@Andy: Fossil è stato creato dal creatore di SQLite. Non è poi così sorprendente :-)

— Jörg W Mittag

1

@Andy: mi fiderei di SQLite molto più di Oracle o MSSQL. Non c'è da meravigliarsi che sia il database SQL più usato là fuori, con un enorme margine. Inoltre è quello portato su architetture diverse, ognuna con le proprie sfide, rendendo il codice condiviso incredibilmente a prova di proiettile.

— Javier,

1

@Javier Non mi fiderei di Sqlite tanto quanto MSSQL o Oracle; come ha detto Mike, la parte in-process mi spaventa, come se la tua app dovesse morire e ora il tuo DB potrebbe essere danneggiato. Con un database client / server, il client che muore interrompe la transazione. Per non dire che è impossibile corrompere i DB CS, ma penso che sia meno probabile che avere il motore DB combinato con l'applicazione.

— Andy,

5

@Andy, ecco a cosa servono le transazioni. Indipendentemente dal punto in cui si interrompe un buon motore DB, una determinata transazione viene impegnata o meno. L'implementazione di commit atomici di SQLite ( sqlite.org/atomiccommit.html ) è particolarmente sofisticata.

— Javier,

10

Un filesystem è un database. Non un database relazionale, ovviamente, ma la maggior parte sono archivi chiave / valore molto efficienti. E se i tuoi schemi di accesso sono ben progettati per un archivio di valori-chiave (ad es. Il formato del repository git), l'uso di un database probabilmente non offre vantaggi significativi rispetto all'utilizzo del filesystem. (In effetti, è solo un altro strato di astrazione a mettersi in mezzo.)
Molte funzionalità del database sono solo un bagaglio extra. Ricerca a testo integrale? La ricerca full-text ha senso per il codice sorgente? O devi tokenizzare diversamente? Ciò richiede anche che i file completi vengano archiviati ad ogni revisione, il che è insolito. Molti sistemi di controllo della versione memorizzano i delta tra le revisioni dello stesso file per risparmiare spazio, ad esempio Subversion e Git (almeno, quando si utilizzano file pack).
I requisiti multipiattaforma rendono l'utilizzo di un database più impegnativo.

La maggior parte degli strumenti di controllo della versione sono progettati per funzionare su più piattaforme. Per gli strumenti di controllo centralizzato della versione, ciò influisce solo sul componente server, ma è ancora difficile fare affidamento su un singolo server di database poiché gli utenti Unix non possono installare Microsoft SQL Server e gli utenti Windows potrebbero non essere disposti a installare PostgreSQL o MySQL. Il filesystem è il minimo comune denominatore. Tuttavia, esistono diversi strumenti in cui il server deve essere installato su un computer Windows e quindi richiedono SQL Server, ad esempio SourceGear Vault e Microsoft Team Foundation Server .

I sistemi di controllo della versione distribuita lo rendono ancora più impegnativo, poiché ogni utente ottiene una copia del repository. Ciò significa che ogni utente ha bisogno di un database in cui inserire il repository. Ciò implica che il software:
1. È limitato a un sottoinsieme di piattaforme in cui esiste un database specifico
2. Targeting di un singolo back-end di database multipiattaforma (ad esempio SQLite).
3. Si rivolge a un back-end di archiviazione collegabile, in modo che uno possa usare qualsiasi database desiderasse (possibilmente includendo il filesystem).
La maggior parte dei sistemi di controllo della versione distribuita, quindi, usa semplicemente il filesystem. Un'eccezione notevole è Veracity di SourceGear , che può archiviare in un database SQLite (utile per i repository locali) o in un database relazionale come SQL Server (probabilmente utile per un server.) La loro offerta ospitata su cloud può utilizzare un back-end di archiviazione non relazionale come Amazon SimpleDB , ma non so che sia vero.

— Edward Thomson
fonte

Proprio come forse il commento dell'avvocato del diavolo, la maggior parte delle persone che pongono questo tipo di domande "perché non usare un database" sembrano significare "perché non usare un RDBMS?" con tutta la conformità ACID e altri problemi coinvolti. Il fatto che tutti i file system siano già database di loro stessi sono già stati scartati.

— mikebabcock,

6

Per quanto ho visto in molte offerte sembra che i file siano "abbastanza buoni" per il lavoro, qualcosa di ragionevole, tenendo conto che alla fine della giornata anche l'output di VCSes è un file.

Ci sono molte aziende che offrono un back-end RDBMS con un'interfaccia svn / git / etc, quindi ciò che si chiede praticamente esiste già.

— Dimitrios Mistriotis
fonte

5

Direi che è perché la struttura dei dati primari di un sistema di controllo della versione è un DAG, che si associa molto male ai database. Molti dati sono anche indirizzabili sul contenuto, che inoltre è mappato su database in modo molto scarso.

L'integrità dei dati non è l'unica preoccupazione di un VCS, ma riguarda anche l' integrità della cronologia delle versioni , di cui i database non sono molto abili. In altre parole, quando recuperi una versione, non solo devi assicurarti che la versione non abbia difetti attuali, ma anche che nulla nella sua intera storia è stato alterato di nascosto.

VCS è anche un prodotto di consumo oltre a un prodotto aziendale. Le persone li usano in piccoli progetti hobby personali. Se aggiungi la seccatura di installare e configurare un server di database, alienerai gran parte di quella parte del mercato. Immagino che non vedi molte installazioni di Vault e TFS a casa. È la stessa ragione per cui i fogli di calcolo e gli elaboratori di testi non usano i database.

Inoltre, questo è più un motivo per DVCS, ma non usare un database lo rende estremamente portatile. Posso copiare il mio albero dei sorgenti su una chiavetta USB e riutilizzarlo su qualsiasi macchina, senza dover configurare un processo del server di database.

Per quanto riguarda il danneggiamento durante il commit, VCS utilizza le stesse tecniche esatte come i database per impedire l'accesso simultaneo, le operazioni di make atomiche, ecc corruzioni in entrambi sono molto rari, ma non succede . A tutti gli effetti, un archivio dati VCS è un database.

— Karl Bielefeldt
fonte

1

"mappa su database molto male" Eppure Vault e TFS fanno proprio questo. "L'integrità dei dati non è l'unica preoccupazione di un VCS, ma riguarda anche l'integrità della cronologia delle versioni, di cui i database non sono molto abili." Non riesco a vedere come l'archiviazione della cronologia delle versioni si presti ai file su un database soprattutto da quando ho nominato i prodotti che fanno proprio questo. ". Le corruzioni in entrambi sono molto rare, ma accadono." Nessuno di questi risultati nella prima pagina parla del danneggiamento del database del server Vault. L'unico link che parla anche del software Vault, il problema è che il WC è stato danneggiato.

— Andy,

"A tutti gli effetti, un archivio dati VCS è un database." Bene ... questo è il mio punto. Perché non limitarsi a inserire i dati in un vero sistema di database invece di creare il proprio?

— Andy,

2

@Andy Sì, è un database, ma non tutti i database sono sostituibili l'uno con l'altro. Ogni database ha una certa visione del mondo (ad esempio, i DB SQL implementano sostanzialmente il modello relazionale). Poiché questa risposta fornisce dettagli, i dati archiviati da un VCS e il modo in cui i dati vengono utilizzati non si adattano al modello relazionale. Non sono sicuro che alcuni db NoSQL facciano meglio, ma sono piuttosto nuovi e devono ancora dimostrare la loro superiorità (per alcuni ricordo ricordi di gravi problemi di integrità). E poi ci sono tutte le altre questioni al di sopra di questo.

I DAG vengono utilizzati solo in DVCS (a meno che non si consideri una cronologia lineare un DAG eccezionalmente semplice, che è, ma non è in realtà un'astrazione utile.) Quando la cronologia è lineare, con i changeset che aumentano monotonicamente, un database SQL ha molto più senso .

— Edward Thomson,

Aumentare monotonicamente i numeri di versione non ha molto senso per i VCS. Ne ho usati un bel numero, e quelli con numeri di versione centralizzati (CVS e SVN sono i 2 con cui ho più familiarità) tendono ad essere un dolore con cui fondersi. E anche quelli usano i DAG quando tentano di fare l'unione. Solo perché la loro rappresentazione di archiviazione non è basata su questo non significa che non sia utilizzata.

— Mike Larsen,

2

Migliore ripristino di emergenza (scenario peggiore: lo analizzeremo ad occhio, come ai vecchi tempi)
Semplificare il rilevamento e il debug di tali disastri, probabilmente causati da guasti nel sistema VCS.
Riduzione del numero di dipendenze. (non dimentichiamo che uno di quei sistemi sta gestendo il kernel e l'altro avrebbe dovuto)
Un editor di testo è sempre disponibile. (Licenze MS SQL Server ... non così tanto)

— ZJR
fonte

Questa risposta è semplicemente negativa. L'unico punto veramente vero è la riduzione del numero di dipendenze. Entrambi i sistemi di backup dovrebbero essere alla pari come dovresti fare backup adeguati, il debug delle applicazioni DB non è più difficile del debug delle applicazioni che scrivono file e l'editor di testo è sempre disponibile? Non so nemmeno quale sia il tuo punto, poiché il VCS non utilizzerà esso stesso un editor di testo, e ci sono altri server DB là fuori (Sqlite, Postgre, MySql, ecc.), Quindi se VUOI un La mancanza della soluzione supportata da db di un server db non dovrebbe essere un fattore.

— Andy,

1

@Andy ... i programmatori useranno un editor di testo. Sai, la modifica del testo è ancora disponibile come funzione secondaria anche nel tuo IDE preferito.

— ZJR,

1

@Andy sqliteè l'unica alternativa possibile ai file di testo, data la grande quantità di scenari distribuiti serviti dai moderni DVCS. (idk, forse potresti aver perso la parte "distribuita" di DVCS) Qualsiasi altra cosa sarebbe troppo ingombrante (configurazione + firewall + licenza) o addirittura sciocca per essere distribuita . Quindi fare di nuovo uno scenario peggiore postmortem a un sqlite potrebbe rivelarsi difficile.

— ZJR,

1

@ZJR: Non credo che la domanda originale abbia mai specificato il controllo della versione distribuita, che chiedeva sui sistemi di controllo della versione in generale. Inoltre, l'argomento dell'editor di testo è un po 'piatto, poiché molti sistemi non memorizzano solo file di testo piatti. Anche git ha molti formati di file binari (oggetti sciolti, file pack, ecc.) Che rendono inutile il tuo editor di testo.

— Edward Thomson,

@ZJR In che modo la modifica del codice in un editor di testo è rilevante per l'archivio di backup di un VCS? Stai suggerendo la modifica manuale, ad esempio il database SVN? Inoltre, la mia domanda non si limita al DVCS, quindi non so perché la stai affrontando.

— Andy,

2

Fossil è un eccellente sistema di controllo della versione distribuita (DVCS) e utilizza SQLite per l'archiviazione, senza file di testo normale.

Mi piace molto che sia integrato: tracciamento dei bug, Wiki e che sia davvero distribuito. Voglio dire, puoi davvero lavorare offline e correggere bug.

Fossil utilizza Sqlite come formato di file dell'applicazione. Nel keynote di PgCon il Dr. Richard Hipp spiega quali sono i vantaggi dell'utilizzo di sqlite come un file system dell'applicazione e fa una discussione abbastanza convincente sui vantaggi dell'utilizzo di un database come file system.

Il secondo argomento principale era che SQLite doveva essere visto come un formato di file dell'applicazione, un'alternativa all'invenzione di formati di file propri o all'utilizzo di XML ZIPped. L'affermazione "SQLite non sostituisce PostgreSQL. SQLite è un sostituto di fopen () ”nail that (slide 21). Infine, Richard ha posto molta enfasi sul fatto che SQLite si prende cura dei tuoi dati (crash-safe, ACID) use-the-index.com

Ora il Dr. Hipp ha affrontato le preoccupazioni sul salvataggio del codice in un database

Perché Fossil si basa su SQLite anziché su un database NoSQL distribuito?

Fossil non si basa su SQLite. L'attuale implementazione di Fossil utilizza SQLite come archivio locale per il contenuto del database distribuito e come cache per meta-informazioni sul database distribuito che è precompilato per una presentazione semplice e veloce. Ma l'uso di SQLite in questo ruolo è un dettaglio di implementazione e non è fondamentale per la progettazione. Alcune versioni future di Fossil potrebbero eliminare SQLite e sostituire un mucchio di file o un database chiave / valore al posto di SQLite. (In realtà, è molto improbabile che accada dal momento che SQLite funziona incredibilmente bene nel suo ruolo attuale, ma il punto è che omettere SQLite da Fossil è una possibilità teorica.)

— elviejo79
fonte