Por que os sistemas de controle de origem ainda são geralmente suportados por arquivos?

22

Parece que mais sistemas de controle de origem ainda usam arquivos como meio de armazenar os dados da versão. O Vault e o TFS usam o Sql Server como armazenamento de dados, o que eu acho que seria melhor para a consistência dos dados e a velocidade.

Então, por que o SVN, acredito que o GIT, o CVS, etc ainda usa o sistema de arquivos como essencialmente um banco de dados? MSSQL, Oracle, Postgre, etc)?

Edição: Eu acho que outra maneira de fazer minha pergunta é "por que os desenvolvedores de VCS lançam seu próprio sistema estruturado de armazenamento de dados em vez de usar um existente?"

version-control

— Andy
fonte

29

O que você acha que a maioria dos bancos de dados usa como apoio básico? A maioria usa arquivos (no entanto, alguns usam acesso direto a discos rígidos). Você pode ter todos os recursos de um banco de dados usando "apenas arquivos".

— Joachim Sauer #

2

@JoachimSauer Fair point, mas é claro que você teria que criar um banco de dados por conta própria. O que é bobagem se o conjunto de recursos desejado estiver próximo aos das soluções existentes e não tiver boas razões para não usar nenhuma delas.

1

@JoachimSauer Sim, eu sei disso, mas os sistemas DBM têm maneiras de garantir que nada inconsistente entre no banco de dados. A menos que esses repositórios baseados em arquivos estejam usando algo como NTSF Transacional, ainda há a possibilidade de estar corrompido. E confio mais em um banco de dados real do que em um conjunto de desenvolvedores essencialmente reinventando a roda, pois acho que podemos concordar que os sistemas de controle de origem exigem integridade dos dados.

— Andy

2

@delnan Suporte transacional e consistência interna. Agora estamos restaurando nosso repositório SVN da fita b / c que o servidor SVN não gravou corretamente em todos os arquivos que deveria. Também pesquisando grandes volumes de dados. O que quero dizer é: por que tentar reinventar a roda?

— Andy Andy

7

Todos os principais sistemas operacionais vêm com um sistema de arquivos embutido. Todos esses sistemas de arquivos têm a mesma funcionalidade básica (arquivos, pastas, persistência do mesmo). Basicamente, um banco de dados é uma dependência extra que o usuário final precisa instalar e manter atualizado. O controle da fonte não é o negócio principal da maioria das pessoas (a menos que você seja o sourceforge ou o github). O VC é frequentemente instalado nos servidores através da linha de comando pelo mais novo membro da equipe. A facilidade de instalação e configuração é importante.

— precisa saber é o seguinte

23

TL; DR: Poucos sistemas de controle de versão usam um banco de dados porque não é necessário.

Como pergunta para resposta a uma pergunta, por que não? Quais benefícios os sistemas de banco de dados "reais" oferecem sobre um sistema de arquivos nesse contexto?

Considere que o controle de revisão geralmente monitora alguns metadados e muitas diferenças de texto. O texto não é armazenado em bancos de dados com mais eficiência e a indexabilidade do conteúdo não será um fator.

Vamos supor que o Git (por uma questão de argumento) tenha usado um BDB ou SQLite DB como back-end para armazenar dados. O que seria mais confiável nisso? Qualquer coisa que possa corromper arquivos simples também pode corromper o banco de dados (já que também é um arquivo simples com uma codificação mais complexa).

Do paradigma do programador de não otimizar, a menos que seja necessário, se o sistema de controle de revisão é rápido o suficiente e funciona de maneira confiável, por que alterar todo o design para usar um sistema mais complexo?

— mikebabcock
fonte

2

TLDR? Sua resposta foi duas vezes maior e a pergunta foi bem curta!

— Brad

25

@ Brad As três palavras a seguir TL;DRsão a versão resumida das respostas, não uma declaração de que a pergunta é muito longa e que ele não a leu antes de responder.

6

@ Andy Mercurial também tem "grep na história", e o git provavelmente também. Também já é muito rápido. Quanto a deixar as coisas para especialistas: as pessoas que desenvolvem VCSs são especialistas.

3

Só quero acrescentar que eu entendo o seu ponto; se o VCS grava dados incorretos, não importa se está gravando esses dados em um arquivo ou banco de dados. O outro lado é que os repositórios baseados em arquivos provavelmente estão gravando em mais de um arquivo por vez e normalmente não há suporte transacional para isso. Se um arquivo gravar, mas outro falhar, seu VCS estará corrompido, e as tabelas de gravação múltipla em um banco de dados. transação será confirmada por falha como uma unidade. Sinto que um grupo de desenvolvedores que cria software de banco de dados tem mais experiência com isso do que as pessoas que escrevem SVN ... mas talvez eu esteja errado.

— Andy

6

Sua escolha do git "por uma questão de argumento" é um ponto importante aqui: o git tem um modelo muito bom para escrever seus objetos, mas muitas ferramentas não. Com o git, se o computador estiver desligado no meio de um commit, você terá gravado alguns dos objetos no sistema de arquivos e eles ficarão inacessíveis. Com outros VCSs, você pode ter acrescentado as alterações à metade dos arquivos (e a confusão se segue.) Você pode argumentar que outras ferramentas de controle de versão são mal projetadas (e você estaria certo), mas quando está escrevendo um VCS, é É muito mais fácil usar uma transação SQL e deixá-la fazer a coisa certa.

— Edward Thomson

25

Você parece estar fazendo muitas suposições, possivelmente com base em sua experiência com SVN e CVS.

Git e Mercurial são basicamente como SVN e CVS

Comparar git e CVS é como comparar um iPad e um Atari. O CVS foi criado quando dinossauros vagavam pela Terra . O Subversion é basicamente uma versão aprimorada do CVS. Assumir que sistemas modernos de controle de versão como git e Mercurial funcionem como eles faz muito pouco sentido.

Um banco de dados relacional é mais eficiente que um banco de dados de propósito único

Por quê? Os bancos de dados relacionais são realmente complicados e podem não ser tão eficientes quanto os de uso único. Algumas diferenças em cima da minha cabeça:

Os sistemas de controle de versão não precisam de bloqueio complicado, pois você não pode fazer vários commit ao mesmo tempo.
Os sistemas de controle de versão distribuído precisam ser extremamente eficientes em termos de espaço, pois o banco de dados local é uma cópia completa do repositório.
Os sistemas de controle de versão precisam apenas procurar dados de duas maneiras específicas (por autor, por ID de revisão, às vezes, pesquisa em texto completo). Criar seu próprio banco de dados que possa lidar com pesquisas de autor / ID de revisão é trivial e as pesquisas de texto completo não são muito rápidas em nenhum banco de dados relacional que eu tentei.
Os sistemas de controle de versão precisam funcionar em várias plataformas. Isso dificulta o uso de um banco de dados que precisa ser instalado e executado como um serviço (como MySQL ou PostgreSQL).
Os sistemas de controle de versão em sua máquina local só precisam estar em execução quando você está fazendo algo (como uma confirmação). Deixar um serviço como o MySQL sendo executado o tempo todo, caso você queira fazer uma consolidação é um desperdício.
Na maioria das vezes, os sistemas de controle de versão nunca desejam excluir o histórico, basta anexá-lo. Isso pode levar a diferentes otimizações e métodos diferentes de proteção da integridade.

Bancos de dados relacionais são mais seguros

Novamente, por que? Você parece supor que, como os dados são armazenados em arquivos, sistemas de controle de versão como git e Mercurial não possuem confirmações atômicas , mas possuem . Os bancos de dados relacionais também armazenam seus bancos de dados como arquivos. É notável aqui que o CVS não realiza confirmações atômicas, mas isso é provável porque é da idade das trevas, não porque eles não usam bancos de dados relacionais.

Há também a questão de proteger os dados contra corrupção, uma vez que estejam no banco de dados, e novamente a resposta é a mesma. Se o sistema de arquivos estiver corrompido, não importa qual banco de dados você está usando. Se o sistema de arquivos não estiver corrompido, seu mecanismo de banco de dados poderá estar quebrado. Não vejo por que um banco de dados de controle de versão seria mais propenso a isso do que um banco de dados relacional.

Eu diria que os sistemas distribuídos de controle de versão (como git e Mercurial) são melhores para proteger seu banco de dados do que o controle centralizado de versão, pois você pode restaurar o repositório inteiro de qualquer clone. Portanto, se o servidor central combinar espontaneamente, juntamente com todos os seus backups, você poderá restaurá-lo executando git initno novo servidor e na máquinagit push de qualquer desenvolvedor .

Reinventar a roda é ruim

Só porque você pode usar um banco de dados relacional para qualquer problema de armazenamento não significa que você deveria . Por que você usa arquivos de configuração em vez de um banco de dados relacional? Por que armazenar imagens no sistema de arquivos quando você pode armazenar os dados em um banco de dados relacional? Por que manter seu código no sistema de arquivos quando você pode armazenar tudo em um banco de dados relacional?

"Se tudo que você tem é um martelo, tudo parece um prego."

Há também o fato de que os projetos de código aberto podem se reinventar sempre que for conveniente, já que você não possui os mesmos tipos de restrições de recursos que os projetos comerciais. Se você tem um voluntário especialista em escrever bancos de dados, por que não usá-los?

Quanto ao motivo pelo qual confiaríamos aos escritores dos sistemas de controle de revisão para saber o que estão fazendo. Não posso falar por outros VCs, mas estou bastante confiante de que Linus Torvalds entende sistemas de arquivos .

Por que alguns sistemas comerciais de controle de versão usam um banco de dados relacional?

Provavelmente, alguma combinação do seguinte:

Alguns desenvolvedores não querem escrever bancos de dados.
Os desenvolvedores de sistemas comerciais de controle de versão têm restrições de tempo e recursos, portanto, não podem se dar ao luxo de escrever um banco de dados quando já tiverem algo próximo do que desejam. Além disso, os desenvolvedores são caros e os desenvolvedores de bancos de dados (como as pessoas que escrevem bancos de dados) provavelmente são mais caros, já que a maioria das pessoas não tem esse tipo de experiência.
Os usuários de sistemas comerciais de controle de versão são menos propensos a se preocupar com a sobrecarga de configurar e executar um banco de dados relacional, já que eles já possuem um.
É mais provável que os usuários de sistemas comerciais de controle de versão desejem um banco de dados relacional apoiando seus dados de revisão, pois isso pode se integrar melhor aos seus processos (como backups, por exemplo).

— Restabelecer Monica
fonte

1

Uma coisa: os commit SVN são atômicos. Na verdade, é um ponto de venda importante (ou pelo menos era, quando eles precisavam convencer os usuários de CSV a mudar).

1

@ delnan - Observe que há uma grande diferença entre a atomicidade teórica que você obtém, svnonde diferentes diretórios em seu diretório de trabalho podem estar em svnrevisões diferentes e a verdadeira atomicidade ampla do repositório que você obtém com gitou hg.

— Mark Booth

2

@ Andy E meu argumento é que você pode lidar exatamente com esses mesmos cenários sem um banco de dados relacional completo. Se duas pessoas confirmarem ao mesmo tempo, o servidor poderá executar uma após a outra. Esse não é um recurso complicado de implementar. Se você quiser fazer isso com um usuário local, basta ter um arquivo de bloqueio. Quando você inicia uma confirmação, obtenha um bloqueio no arquivo. Quando você terminar uma confirmação, libere o bloqueio. Se você deseja permitir confirmações para várias ramificações de uma só vez, use um arquivo de bloqueio para cada ramificação. Claro, o SQLite faria isso por mim, mas não é necessário .

— Reintegrar Monica

1

Da mesma forma, implementar um diário básico também não é complicado. (1) Escreva o novo commit em um arquivo. (2) Copie o arquivo de índice antigo. (3) Escreva um novo arquivo de índice. (4) Exclua a cópia do arquivo de índice antigo. Se você falhar nas etapas 1, 2 ou 4, basta limpar os novos arquivos que você criou. Se você falhar na etapa 3, basta copiar o arquivo de índice antigo novamente. Alguém que entenda melhor os sistemas de arquivos provavelmente poderia fazer uma versão muito mais eficiente disso, mas você sempre pode fazer referência ao código-fonte do SQLite se precisar (é de domínio público).

— Reintegrar Monica

1

@BrendanLong Grandes pontos. Aprecie a discussão. Só para esclarecer, acho que há vantagens e desvantagens nos dois tipos de lojas de apoio, não acredito que haja apenas uma resposta correta. No entanto, fiquei meio surpreso que parece haver apenas três (quatro se você contar o Vault e o Vercity separadamente) que usam SQL e a grande maioria não, isso é tudo.

— Andy

18

Na verdade, é svnusado para usar o BDB para repositórios. Eventualmente, isso foi eliminado porque estava propenso a quebrar.

Outro VCS que atualmente usa um banco de dados (SQLite) é fossil. Ele também integra um rastreador de erros.

Meu palpite sobre o verdadeiro motivo é que os VCS funcionam com muitos arquivos. Os sistemas de arquivos são apenas outro tipo de banco de dados (hierárquico, focado na eficiência do armazenamento CLOB / BLOB). Bancos de dados normais não lidam bem com isso porque não há razão para + sistemas de arquivos já existirem.

— Mike Larsen
fonte

1

O BDB não conta exatamente como confiável - como o SQLite, é um banco de dados em processo. Dito isso, acho que a confiabilidade do Oracle / MSSQL / MySQL / Postgres, dependendo de como você os configura, não é muito diferente dos sistemas de arquivos. O principal problema é que o RDBMS não é construído para as estruturas hierárquicas e gráficas com as quais os VCS geralmente trabalham. E, nesse caso, os sistemas de arquivos simplesmente vencem.

— Mike Larsen

3

@ Andy: Fossil foi criado pelo criador do SQLite. Não é realmente tão surpreendente :-)

— Jörg W Mittag

1

@ Andy: eu confiaria no SQLite muito mais do que Oracle ou MSSQL. Não é de admirar que seja o banco de dados SQL mais usado por aí, por uma margem enorme. Também é portado para a maioria das arquiteturas diferentes, cada uma com seu próprio conjunto de desafios, tornando o código compartilhado incrivelmente à prova de balas.

— Javier

1

@Javier Eu não confiaria tanto no Sqlite quanto no MSSQL ou Oracle; como Mike disse que a parte em processo me assusta, como se seu aplicativo morresse e que poderia deixar seu banco de dados corrompido agora. Com um banco de dados cliente / servidor, o cliente que morre aborta a transação. Para não dizer que é impossível para os CS DBs corromper, mas eu acho que é menos provável do que ter o mecanismo de DB combinado ao aplicativo.

— Andy Andy

5

@ Andy, é para isso que servem as transações. Não importa em que ponto você mate um bom mecanismo de banco de dados, uma determinada transação é confirmada ou não. A implementação de commits atômicos do SQLite ( sqlite.org/atomiccommit.html ) é particularmente sofisticada.

— Javier

10

Um sistema de arquivos é um banco de dados. Não é um banco de dados relacional, é claro, mas a maioria é um armazenamento de chave / valor muito eficiente. E se seus padrões de acesso foram bem projetados para um armazenamento de valores-chave (por exemplo, o formato de repositório git), o uso de um banco de dados provavelmente não oferece vantagens significativas em relação ao uso do sistema de arquivos. (De fato, é apenas mais uma camada de abstração para atrapalhar.)
Muitos dos recursos do banco de dados são apenas bagagem extra. Pesquisa de texto completo? A pesquisa de texto completo faz sentido para o código-fonte? Ou você precisa tokenizá-lo de maneira diferente? Isso também requer que você armazene arquivos completos a cada revisão, o que é incomum. Muitos sistemas de controle de versão armazenam deltas entre revisões do mesmo arquivo para economizar espaço, por exemplo, Subversion e Git (pelo menos ao usar arquivos de pacote).
Os requisitos de plataforma cruzada tornam o uso de um banco de dados mais desafiador.

A maioria das ferramentas de controle de versão é criada para executar em várias plataformas. Para ferramentas centralizadas de controle de versão, isso afeta apenas o componente do servidor, mas ainda é difícil confiar em um único servidor de banco de dados, pois os usuários do Unix não podem instalar o Microsoft SQL Server e os usuários do Windows podem não querer instalar o PostgreSQL ou MySQL. O sistema de arquivos é o denominador menos comum. No entanto, existem várias ferramentas nas quais o servidor deve ser instalado em uma máquina Windows e, portanto, requer o SQL Server, por exemplo, SourceGear Vault e Microsoft Team Foundation Server .

Os sistemas distribuídos de controle de versão tornam isso ainda mais desafiador, pois cada usuário recebe uma cópia do repositório. Isso significa que todo usuário precisa de um banco de dados para colocar o repositório. Isso implica que o software:
1. É limitado a um subconjunto de plataformas em que existe um banco de dados específico
2. Destina um único back-end de banco de dados que é multiplataforma (por exemplo, SQLite).
3. Tem como objetivo um back-end de armazenamento conectável, para que você possa usar o banco de dados que desejar (possivelmente incluindo o sistema de arquivos).
A maioria dos sistemas de controle de versão distribuídos, portanto, apenas usa o sistema de arquivos. Uma exceção notável é o Veracity do SourceGear , que pode armazenar em um banco de dados SQLite (útil para repositórios locais) ou em um banco de dados relacional como o SQL Server (possivelmente útil para um servidor). A oferta hospedada na nuvem pode usar um back-end de armazenamento não relacional como o Amazon SimpleDB , mas não sei se isso é verdade.

— Edward Thomson
fonte

Assim como o advogado do diabo comenta, talvez, a maioria das pessoas que faz esses tipos de perguntas "por que não usar um banco de dados" parece significar "por que não usar um RDBMS?" com toda a conformidade com o ACID e outros problemas envolvidos. O fato de todos os sistemas de arquivos já serem bancos de dados próprios já foi descartado.

— Mikebabcock

6

Até onde eu já vi em muitas ofertas, parece que os arquivos são "bons o suficiente" para o trabalho, algo razoável, levando em consideração que no final do dia a saída do VCSes também é arquivos.

Existem muitas empresas que oferecem um back-end RDBMS com uma interface svn / git / etc, portanto, o que você está pedindo basicamente já existe.

— Dimitrios Mistriotis
fonte

5

Eu diria que é porque a estrutura de dados primária de um sistema de controle de versão é um DAG, que mapeia muito mal os bancos de dados. Muitos dados também são endereçáveis, o que também mapeia muito mal os bancos de dados.

A integridade dos dados não é a única preocupação de um VCS, eles também se preocupam com a integridade do histórico de versões , nas quais os bancos de dados não são muito bons. Em outras palavras, ao recuperar uma versão, você precisa não apenas garantir que a versão não tenha falhas atuais, mas também que nada em toda a sua história tenha sido sub-repticiamente alterado.

VCS também são um produto de consumo, além de um produto corporativo. As pessoas as usam em pequenos projetos de hobby individuais. Se você adicionar o incômodo de instalar e configurar um servidor de banco de dados, irá alienar grande parte dessa parte do mercado. Acho que você não vê muitas instalações do Vault e TFS em casa. É a mesma razão pela qual planilhas e processadores de texto não usam bancos de dados.

Além disso, esse é mais um motivo para o DVCS, mas o não uso de um banco de dados o torna extremamente portátil. Posso copiar minha árvore de origem em um pen drive e reutilizá-la em qualquer máquina, sem precisar configurar um processo do servidor de banco de dados.

Tanto quanto corromper durante commits, VCS usa as mesmas técnicas exatas como bancos de dados para impedir o acesso simultâneo, as transações make atômicas, etc. Corruptions em ambos são muito raros, mas eles não acontecer . Para todos os efeitos, um armazenamento de dados VCS é um banco de dados.

— Karl Bielefeldt
fonte

1

"mapeia muito mal os bancos de dados". No entanto, o Vault e o TFS fazem exatamente isso. "A integridade dos dados não é a única preocupação de um VCS, eles também estão preocupados com a integridade do histórico de versões, nas quais os bancos de dados não são muito bons". Não consigo ver como o armazenamento do histórico de versões se presta a arquivos em um banco de dados, especialmente porque nomeei produtos que fazem exatamente isso. ". Corrupções em ambos são muito raras, mas acontecem." Nenhum desses resultados na primeira página fala sobre o banco de dados do servidor do Vault estar corrompido. O único link que fala sobre o software Vault é o WC corrompido.

— Andy

"Para todos os efeitos, um repositório de dados VCS é um banco de dados." Bem ... esse é o meu ponto. Por que não colocar os dados em um sistema de banco de dados real, em vez de criar o seu próprio?

— Andy

2

@ Andy Sim, é um banco de dados, mas nem todos os bancos de dados são substituíveis um pelo outro. Cada banco de dados tem uma certa visão do mundo (por exemplo, os bancos de dados SQL basicamente implementam o modelo relacional). Como essa resposta detalha, os dados que um VCS armazena e a maneira como os dados são usados não se encaixam no modelo relacional. Não tenho certeza se algum NoSQL db se sai melhor, mas eles são novos e ainda precisam provar sua superioridade (lembro-me de alguns problemas graves de integridade). E depois há todas as outras questões em cima disso.

DAGs são usados apenas no DVCS (a menos que você considere um histórico linear um DAG excepcionalmente simples, o que é, mas isso não é realmente uma abstração útil.) Quando seu histórico é linear, com conjuntos de alterações que aumentam monotonicamente, um banco de dados SQL faz muito mais sentido .

— Edward Thomson

O aumento monotônico de números de versão não faz muito sentido para VCSes. Eu usei um bom número deles, e aqueles com números de versão centralizados (CVS e SVN são os 2 com os quais eu estou mais familiarizado) tendem a ser uma dor de se mesclar. E mesmo aqueles usam DAGs quando tentam fazer a mesclagem. Só porque a representação de armazenamento deles não se baseia, não significa que não seja usado.

— Mike Larsen

2

Melhor recuperação de desastre (pior cenário: analisaremos a olho nu, como nos velhos tempos)
Facilitando o rastreamento e a depuração desses desastres, possivelmente causados por falhas no sistema VCS.
Diminuindo o número de dependências. (não vamos esquecer que um desses sistemas está lidando com o kernel e o outro deveria)
Um editor de texto está sempre disponível. (Licenças do MS SQL Server ... nem tanto)

— ZJR
fonte

Essa resposta é ruim. O único ponto realmente verdadeiro é diminuir o número de dependências. Ambos os sistemas de backup devem estar em pé de igualdade, assim como você deve fazer backups apropriados, a depuração de aplicativos de banco de dados não é mais difícil do que a depuração de aplicativos que escrevem arquivos e o editor de texto está sempre disponível? Eu nem sei qual é o seu ponto, já que o VCS não usará um editor de texto e existem outros servidores de banco de dados por aí (Sqlite, Postgre, MySql etc.), portanto, se você QUER A falta de um servidor db na solução com suporte a banco de dados não deve ser um fator.

— Andy

1

@ Andy ... os programadores vão usar para usar um editor de texto. Você sabe, a edição de texto ainda está disponível como uma função secundária, mesmo no seu IDE favorito.

— ZJR

1

O @Andy sqliteé a única alternativa possível aos arquivos de texto, dada a grande quantidade de cenários distribuídos que o DVCS moderno atende. (idk, talvez você tenha perdido a parte "distribuída" do DVCS) Qualquer outra coisa seria muito complicada (configuração + firewall + licença) ou até boba para ser distribuída . Então, novamente, fazer o pior cenário pós-morte para um sqlite pode ser difícil.

— ZJR 05/11

1

@ZJR: Acho que a pergunta original nunca especificou o controle de versão distribuído, ela perguntou sobre os sistemas de controle de versão em geral. Além disso, o argumento do seu editor de texto é um pouco simples, pois muitos sistemas não armazenam apenas arquivos de texto simples. Até o git tem muitos formatos de arquivos binários (objetos soltos, arquivos de pacotes, etc.) que tornam seu editor de texto inútil.

— Edward Thomson

@ZJR Como a edição de código em um editor de texto é relevante para o armazenamento de um VCS? Você está sugerindo uma edição manual, digamos o banco de dados do SVN? Além disso, minha pergunta não se limita ao DVCS, então não sei por que você está insistindo nisso.

— Andy

2

O Fossil é um excelente sistema de controle de versão distribuído (DVCS) e usa SQLite para armazenamento, sem arquivos de texto sem formatação.

Eu realmente gosto que ele tenha se integrado: rastreamento de bugs, Wiki e que ele esteja realmente distribuído. Quero dizer, você pode realmente trabalhar offline e corrigir bugs.

O Fossil usa o Sqlite como formato de arquivo do aplicativo. Na palestra da PgCon, o Dr. Richard Hipp explica quais são as vantagens do uso do sqlite como um sistema de arquivos de aplicativos e cria um argumento bastante convincente dos benefícios do uso de um banco de dados como sistema de arquivos.

O segundo tópico principal era que o SQLite deveria ser visto como um formato de arquivo de aplicativo - uma alternativa para inventar formatos de arquivo próprios ou usar XMLs ZIPados. A declaração “SQLite não substitui o PostgreSQL. O SQLite é um substituto para as unhas fopen () ”que (slide 21). Por fim, Richard enfatizou bastante o fato de que o SQLite cuida de seus dados (crash safe, ACID) use-the-index.com

Agora, o Dr. Hipp abordou as preocupações em salvar código em um banco de dados

Por que o Fossil é baseado em SQLite em vez de um banco de dados NoSQL distribuído?

Fossil não é baseado em SQLite. A implementação atual do Fossil usa o SQLite como uma loja local para o conteúdo do banco de dados distribuído e como um cache para meta-informações sobre o banco de dados distribuído pré-computado para uma apresentação rápida e fácil. Mas o uso do SQLite nesta função é um detalhe de implementação e não é fundamental para o design. Alguma versão futura do Fossil pode acabar com o SQLite e substituir uma pilha de arquivos ou um banco de dados de chave / valor no lugar do SQLite. (Na verdade, é muito improvável que isso aconteça, pois o SQLite funciona surpreendentemente bem em sua função atual, mas o ponto é que a omissão do SQLite do Fossil é uma possibilidade teórica.)

— elviejo79
fonte