Pourquoi les systèmes de contrôle des sources sont-ils encore majoritairement sauvegardés avec des fichiers?

22

Il semble que davantage de systèmes de contrôle des sources utilisent encore des fichiers comme moyen de stockage des données de version. Vault et TFS utilisent Sql Server comme magasin de données, ce qui, à mon avis, serait meilleur pour la cohérence des données et la vitesse.

Alors pourquoi SVN, je crois que GIT, CVS, etc. utilisent toujours le système de fichiers comme une base de données essentiellement (je pose cette question car notre serveur SVN vient de se corrompre lors d'un commit normal) au lieu d'utiliser un logiciel de base de données réel ( MSSQL, Oracle, Postgre, etc.)?

EDIT: Je pense qu'une autre façon de poser ma question est "pourquoi les développeurs VCS roulent-ils leur propre système de stockage de données structuré au lieu d'utiliser un existant?"

version-control

— Andy
source

29

Que pensez-vous que la plupart des bases de données utilisent comme support de base? La plupart utilisent des fichiers (quelques-uns utilisent cependant un accès direct aux disques durs). Vous pouvez disposer de toutes les fonctionnalités d'une base de données en utilisant "juste des fichiers".

— Joachim Sauer du

2

@JoachimSauer Fair point, bien que vous deviez alors créer vous-même une base de données. Ce qui est idiot si votre ensemble de fonctionnalités souhaité est proche de celles des solutions existantes et n'ont pas de très bonnes raisons de ne pas utiliser l'une d'entre elles.

1

@JoachimSauer Oui, je m'en rends compte, mais les systèmes DBM ont des moyens de s'assurer que rien d'incohérent ne pénètre dans la base de données. À moins que ces référentiels basés sur des fichiers n'utilisent quelque chose comme Transactional NTSF, il est toujours possible d'être corrompu. Et je fais plus confiance à une vraie base de données qu'à un ensemble de développeurs qui réinventent essentiellement la roue, car je pense que nous pouvons convenir que les systèmes de contrôle des sources nécessitent l'intégrité des données.

— Andy

2

@delnan Support transactionnel et cohérence interne. Nous restaurons maintenant notre dépôt SVN à partir de la bande b / c, le serveur SVN n'a pas correctement écrit dans tous les fichiers qu'il était censé faire. Recherche également d'énormes volumes de données. Mon point est, pourquoi essayer de réinventer la roue.

— Andy

7

Chaque système d'exploitation majeur est livré avec un système de fichiers intégré. Tous ces systèmes de fichiers ont les mêmes fonctionnalités de base (fichiers, dossiers, persistance de ceux-ci). Fondamentalement, une base de données est une dépendance supplémentaire que l'utilisateur final doit installer et maintenir à jour. Le contrôle des sources n'est pas l'activité principale de la plupart des gens (sauf si vous êtes sourceforge ou github). VC est souvent installé sur les serveurs via la ligne de commande par le membre le plus récent de l'équipe. La facilité d'installation et de configuration est importante.

— GlenPeterson

23

TL; DR: Peu de systèmes de contrôle de version utilisent une base de données car elle n'est pas nécessaire.

En tant que question pour une réponse à une question, pourquoi pas? Quels sont les avantages des "vrais" systèmes de base de données par rapport à un système de fichiers dans ce contexte?

Considérez que le contrôle de révision consiste principalement à garder une trace de petites métadonnées et de beaucoup de différences de texte. Le texte n'est pas stocké plus efficacement dans les bases de données, et l'indexabilité du contenu ne sera pas un facteur.

Supposons que Git (pour le bien de l'argument) utilise un BDB ou SQLite DB pour son back-end pour stocker des données. Quoi de plus fiable à ce sujet? Tout ce qui pourrait corrompre des fichiers simples peut également corrompre la base de données (car il s'agit également d'un fichier simple avec un codage plus complexe).

Du paradigme du programmeur de ne pas optimiser à moins que ce ne soit nécessaire, si le système de contrôle de révision est assez rapide et fonctionne de manière suffisamment fiable, pourquoi changer la conception entière pour utiliser un système plus complexe?

— mikebabcock
source

2

TLDR? Votre réponse était deux fois plus longue et la question était vraiment courte!

— Brad

25

@Brad Les trois mots suivants TL;DRsont la version abrégée des réponses, pas une déclaration que la question est trop longue et qu'il ne l'a pas lue avant de répondre.

6

@Andy Mercurial a également "grep dans l'histoire", et git l'a probablement aussi. C'est aussi rapide comme l'éclair. Quant à laisser les choses à un expert: les personnes qui développent des VCS sont des experts.

3

Je veux juste ajouter que je vois votre point; si VCS écrit de mauvaises données, peu importe qu'il écrive ces données dans un fichier ou une base de données. Le revers de la médaille est que les dépôts basés sur des fichiers écrivent probablement dans plus d'un fichier à la fois et normalement il n'y a pas de support transactionnel pour cela, donc si un fichier écrit mais qu'un autre échoue, votre VCS est maintenant corrompu, vs une table mutiple écrit dans une base de données la transaction sera validée pour l'échec en tant qu'unité. J'ai l'impression qu'un groupe de développeurs créant des logiciels de base de données a plus d'expérience avec cela que les gens qui écrivent SVN ... mais peut-être que je me trompe.

— Andy

6

Votre choix de git "pour le bien de l'argument" est un point important ici: git a un très bon modèle pour écrire ses objets, mais pas beaucoup d'outils. Avec git, si l'ordinateur est éteint au milieu d'une validation, vous aurez écrit certains des objets dans le système de fichiers et ils seront simplement inaccessibles. Avec d'autres VCS, vous avez peut-être ajouté les modifications à la moitié des fichiers (et la confusion s'ensuit.) Vous pourriez faire valoir que d'autres outils de contrôle de version sont mal conçus (et vous auriez raison), mais lorsque vous écrivez un VCS, c'est beaucoup plus facile d'utiliser simplement une transaction SQL et de la laisser faire la bonne chose.

— Edward Thomson

25

Vous semblez faire beaucoup d'hypothèses, peut-être basées sur votre expérience avec SVN et CVS.

Git et Mercurial sont fondamentalement comme SVN et CVS

Comparer Git et CVS, c'est comme comparer un iPad et un Atari. CVS a été créé à l'époque où les dinosaures parcouraient la Terre . Subversion est fondamentalement une version améliorée de CVS. En supposant que les systèmes de contrôle de version modernes comme git et Mercurial fonctionnent comme eux, cela n'a pas beaucoup de sens.

Une base de données relationnelle est plus efficace qu'une base de données à usage unique

Pourquoi? Les bases de données relationnelles sont vraiment compliquées et peuvent ne pas être aussi efficaces que les bases de données à usage unique. Quelques différences du haut de ma tête:

Les systèmes de contrôle de version n'ont pas besoin d'un verrouillage compliqué, car vous ne pouvez pas faire plusieurs validations en même temps de toute façon.
Les systèmes de contrôle de version distribués doivent être extrêmement efficaces en termes d'espace, car la base de données locale est une copie complète du dépôt.
Les systèmes de contrôle de version n'ont besoin de rechercher les données que de deux manières spécifiques (par auteur, par ID de révision, parfois recherche en texte intégral). Faire votre propre base de données qui peut gérer les recherches d'ID auteur / révision est trivial et les recherches en texte intégral ne sont pas très rapides dans les bases de données relationnelles que j'ai essayées.
Les systèmes de contrôle de version doivent fonctionner sur plusieurs plates-formes. Cela rend plus difficile l'utilisation d'une base de données qui doit être installée et exécutée en tant que service (comme MySQL ou PostgreSQL).
Les systèmes de contrôle de version sur votre machine locale ne doivent être exécutés que lorsque vous faites quelque chose (comme un commit). Laisser un service comme MySQL fonctionner tout le temps au cas où vous voudriez faire un commit est un gaspillage.
Pour la plupart, les systèmes de contrôle de version ne veulent jamais supprimer l'historique, il suffit de l'ajouter. Cela peut conduire à différentes optimisations et à différentes méthodes de protection de l'intégrité.

Les bases de données relationnelles sont plus sûres

Encore une fois, pourquoi? Vous semblez supposer que parce que les données sont stockées dans des fichiers, les systèmes de contrôle de version comme git et Mercurial n'ont pas de commits atomiques , mais ils en ont. Les bases de données relationnelles stockent également leurs bases de données sous forme de fichiers. Il est notable ici que CVS ne fait pas de commit atomique, mais c'est probablement parce qu'il vient des âges sombres, pas parce qu'ils n'utilisent pas de bases de données relationnelles.

Il y a aussi le problème de la protection des données contre la corruption une fois qu'elles sont dans la base de données, et là encore la réponse est la même. Si le système de fichiers est corrompu, peu importe la base de données que vous utilisez. Si le système de fichiers n'est pas corrompu, votre moteur de base de données peut être endommagé. Je ne vois pas pourquoi une base de données de contrôle de version serait plus sujette à cela qu'une base de données relationnelle.

Je dirais que les systèmes de contrôle de version distribués (comme git et Mercurial) sont meilleurs pour protéger votre base de données que le contrôle de version centralisé, car vous pouvez restaurer l'intégralité du référentiel à partir de n'importe quel clone. Donc, si votre serveur central brûle spontanément, avec toutes vos sauvegardes, vous pouvez le restaurer en l'exécutant git initsur le nouveau serveur, puis git pushdepuis n'importe quelle machine de développeur .

Réinventer la roue est mauvais

Ce n'est pas parce que vous pouvez utiliser une base de données relationnelle pour tout problème de stockage que vous le devriez . Pourquoi utilisez-vous des fichiers de configuration au lieu d'une base de données relationnelle? Pourquoi stocker des images sur le système de fichiers alors que vous pouvez stocker les données dans une base de données relationnelle? Pourquoi garder votre code sur le système de fichiers alors que vous pouvez tout stocker dans une base de données relationnelle?

"Si tout ce que vous avez est un marteau, tout ressemble à un clou."

Il y a aussi le fait que les projets open source peuvent se permettre de réinventer la roue quand cela est pratique, car vous n'avez pas les mêmes types de contraintes de ressources que les projets commerciaux. Si vous avez un bénévole qui est un expert dans la rédaction de bases de données, alors pourquoi ne pas les utiliser?

Quant à savoir pourquoi nous ferions confiance aux auteurs de systèmes de contrôle des révisions pour savoir ce qu'ils font .. Je ne peux pas parler pour les autres VCS, mais je suis assez confiant que Linus Torvalds comprend les systèmes de fichiers .

Pourquoi certains systèmes de contrôle de version commerciaux utilisent-ils alors une base de données relationnelle?

Très probablement une combinaison des éléments suivants:

Certains développeurs ne veulent pas écrire de bases de données.
Les développeurs de systèmes de contrôle de version commerciaux ont des contraintes de temps et de ressources, ils ne peuvent donc pas se permettre d'écrire une base de données lorsqu'ils ont déjà quelque chose de proche de ce qu'ils veulent. En outre, les développeurs sont chers et les développeurs de bases de données (comme dans les personnes qui écrivent des bases de données) sont probablement plus chers, car la plupart des gens n'ont pas ce genre d'expérience.
Les utilisateurs de systèmes de contrôle de version commerciaux sont moins susceptibles de se soucier des frais généraux liés à la configuration et à l'exécution d'une base de données relationnelle, car ils en ont déjà une.
Les utilisateurs de systèmes de contrôle de version commerciaux sont plus susceptibles de vouloir une base de données relationnelle sauvegardant leurs données de révision, car cela peut mieux s'intégrer à leurs processus (comme les sauvegardes par exemple).

— Réintégrer Monica
source

1

Une chose: les commits SVN sont atomiques. En fait, c'est un argument de vente majeur (ou du moins l'était, à l'époque où ils devaient convaincre les utilisateurs de CSV de changer).

1

@delnan - Notez qu'il existe une grande différence entre l' atomicité théorique avec svnlaquelle les différents répertoires de votre répertoire de travail peuvent se trouver à différentes svnrévisions et la véritable atomicité à l'échelle du référentiel avec gitou hg.

— Mark Booth

2

@Andy Et mon point est que vous pouvez gérer ces mêmes scénarios sans une base de données relationnelle complète. Si deux personnes s'engagent en même temps, le serveur peut le faire l'une après l'autre. Ce n'est pas une fonctionnalité compliquée à mettre en œuvre. Si vous voulez le faire avec un utilisateur local, il vous suffit d'avoir un fichier de verrouillage. Lorsque vous démarrez une validation, verrouillez le fichier. Lorsque vous mettez fin à un commit, relâchez le verrou. Si vous souhaitez autoriser les validations sur plusieurs branches à la fois, utilisez un fichier de verrouillage pour chaque branche. Bien sûr, SQLite ferait cela pour moi, mais ce n'est pas nécessaire .

— Rétablir Monica

1

De même, l'implémentation d'un journal de base n'est pas compliquée non plus. (1) Écrivez le nouveau commit dans un fichier. (2) Copiez l'ancien fichier d'index. (3) Écrivez un nouveau fichier d'index. (4) Supprimez la copie de l'ancien fichier d'index. Si vous échouez à l'étape 1, 2 ou 4, il vous suffit de nettoyer les nouveaux fichiers que vous avez créés. Si vous échouez à l'étape 3, il vous suffit de recopier l'ancien fichier d'index. Quelqu'un qui comprend mieux les systèmes de fichiers pourrait probablement en faire une version beaucoup plus efficace, mais vous pouvez toujours référencer le code source de SQLite si vous en avez besoin (c'est le domaine public).

— Rétablir Monica

1

@BrendanLong Grands points. Appréciez la discussion. Juste pour être clair, je pense qu'il y a des avantages et des inconvénients aux deux types de magasins de sauvegarde, je ne pense pas qu'il y ait une seule bonne réponse. Cependant, j'ai été un peu surpris qu'il ne semble y en avoir que trois (quatre si vous comptez Vault et Vercity séparément) qui utilisent SQL et la grande majorité ne l'était pas, c'est tout.

— Andy

18

Actuellement svnutilisé pour utiliser BDB pour les référentiels. Cela a finalement été éliminé car il était susceptible de se casser.

Un autre VCS qui utilise actuellement une base de données (SQLite) est fossil. Il intègre également un traqueur de bogues.

Je suppose que la vraie raison est que les VCS fonctionnent avec beaucoup de fichiers. Les systèmes de fichiers ne sont qu'un autre type de base de données (hiérarchique, axé sur l'efficacité du stockage CLOB / BLOB). Les bases de données normales ne gèrent pas bien cela car il n'y a aucune raison - les systèmes de fichiers existent déjà.

— Mike Larsen
source

1

BDB ne serait pas exactement fiable - comme SQLite, c'est une base de données en cours. Cela dit, je pense que la fiabilité d'Oracle / MSSQL / MySQL / Postgres, selon la façon dont vous les configurez, n'est pas très différente des systèmes de fichiers. Le principal problème est que les SGBDR ne sont pas construits pour les structures hiérarchiques et graphiques avec lesquelles les VCS fonctionnent couramment. Et dans ce cas, les systèmes de fichiers ne font que gagner.

— Mike Larsen

3

@Andy: Fossil a été créé par le créateur de SQLite. Ce n'est pas vraiment surprenant :-)

— Jörg W Mittag

1

@Andy: Je me fierais SQLite beaucoup plus que Oracle ou MSSQL. Il n'est pas étonnant que ce soit la base de données SQL la plus utilisée sur le marché, par une énorme marge. C'est également celui qui est porté sur la plupart des architectures différentes, chacune avec son propre ensemble de défis, ce qui rend le code partagé incroyablement à l'épreuve des balles.

— Javier

1

@Javier Je ne ferais pas autant confiance à Sqlite qu'à MSSQL ou Oracle; comme Mike l'a dit, la partie en cours me fait peur, comme si votre application mourait, ce qui pourrait laisser votre base de données corrompue maintenant. Avec une base de données client / serveur, le client mourant abandonne la transaction. Pour ne pas dire qu'il est impossible pour les bases de données CS de corrompre, mais je pense que c'est moins probable que d'avoir le moteur de base de données combiné avec l'application.

— Andy

5

@Andy, c'est à ça que servent les transactions. Peu importe à quel moment vous tuez un bon moteur de base de données, une transaction donnée est validée ou non. L'implémentation SQLite des commits atomiques ( sqlite.org/atomiccommit.html ) est particulièrement sophistiquée.

— Javier

10

Un système de fichiers est une base de données. Pas une base de données relationnelle, bien sûr, mais la plupart sont des magasins de clés / valeurs très efficaces. Et si vos modèles d'accès sont bien conçus pour un magasin de valeurs-clés (par exemple, le format du référentiel git), l'utilisation d'une base de données n'offre probablement pas d'avantages significatifs par rapport à l'utilisation du système de fichiers. (En fait, c'est juste une autre couche d'abstraction pour se mettre en travers.)
De nombreuses fonctionnalités de la base de données ne sont que des bagages supplémentaires. Recherche en texte intégral? La recherche en texte intégral a-t-elle un sens pour le code source? Ou avez-vous besoin de le symboliser différemment? Cela nécessite également que vous stockiez des fichiers complets à chaque révision, ce qui est rare. De nombreux systèmes de contrôle de version stockent des deltas entre les révisions du même fichier afin d'économiser de l'espace, par exemple Subversion et Git (au moins, lors de l'utilisation de fichiers pack.)
Les exigences multiplateformes rendent l'utilisation d'une base de données plus difficile.

La plupart des outils de contrôle de version sont conçus pour fonctionner sur plusieurs plates-formes. Pour les outils de contrôle de version centralisés, cela n'affecte que le composant serveur, mais il est toujours difficile de s'appuyer sur un seul serveur de base de données car les utilisateurs Unix ne peuvent pas installer Microsoft SQL Server et les utilisateurs Windows peuvent ne pas vouloir installer PostgreSQL ou MySQL. Le système de fichiers est le dénominateur le moins commun. Cependant, il existe plusieurs outils dans lesquels le serveur doit être installé sur une machine Windows et nécessitent donc SQL Server, par exemple SourceGear Vault et Microsoft Team Foundation Server .

Les systèmes de contrôle de version distribués rendent cela encore plus difficile, car chaque utilisateur obtient une copie du référentiel. Cela signifie que chaque utilisateur a besoin d'une base de données dans laquelle placer le référentiel. Cela implique que le logiciel:
1. Est limité à un sous-ensemble de plates-formes où une base de données particulière existe
2. Cible un backend de base de données unique multiplateforme (par exemple, SQLite).
3. Cible un backend de stockage enfichable, afin que l'on puisse utiliser la base de données souhaitée (y compris éventuellement le système de fichiers).
Par conséquent, la plupart des systèmes de contrôle de version distribués utilisent simplement le système de fichiers. Une exception notable est Veracity de SourceGear , qui peut stocker dans une base de données SQLite (utile pour les référentiels locaux) ou une base de données relationnelle comme SQL Server (peut-être utile pour un serveur). Leur offre hébergée dans le cloud peut utiliser un backend de stockage non relationnel comme Amazon SimpleDB , mais je ne sais pas si cela est vrai.

— Edward Thomson
source

Tout comme un avocat du diable commente peut-être, la plupart des gens qui posent ce type de questions "pourquoi ne pas utiliser une base de données" semblent vouloir dire "pourquoi ne pas utiliser un SGBDR?" avec toute la conformité ACID et d'autres problèmes impliqués. Le fait que tous les systèmes de fichiers sont déjà des bases de données de leur propre acabit ayant déjà été supprimés.

— mikebabcock

6

Pour autant que je l'ai vu dans de nombreuses offres, il semble que les fichiers soient "assez bons" pour le travail, quelque chose de raisonnable, compte tenu du fait qu'en fin de compte, la sortie de VCS est également des fichiers.

De nombreuses entreprises proposent un back-end RDBMS avec une interface svn / git / etc, donc ce que vous demandez existe déjà.

— Dimitrios Mistriotis
source

5

Je dirais que c'est parce que la structure de données principale d'un système de contrôle de version est un DAG, qui correspond très mal aux bases de données. De nombreuses données sont également adressables par contenu, ce qui correspond également très mal aux bases de données.

L'intégrité des données n'est pas la seule préoccupation d'un VCS, ils sont également concernés par l' intégrité de l' historique des versions , pour lesquelles les bases de données ne sont pas très bonnes. En d'autres termes, lorsque vous récupérez une version, vous devez non seulement vous assurer que cette version n'a pas de défauts actuels, mais aussi que rien dans son histoire entière n'a été subrepticement modifié.

Les VCS sont également un produit de consommation en plus d'un produit d'entreprise. Les gens les utilisent dans de petits projets de loisirs individuels. Si vous ajoutez les tracas de l'installation et de la configuration d'un serveur de base de données, vous allez aliéner une grande partie de cette partie du marché. Je suppose que vous ne voyez pas beaucoup d'installations Vault et TFS à la maison. C'est la même raison pour laquelle les feuilles de calcul et les traitements de texte n'utilisent pas de bases de données.

De plus, c'est plus une raison pour le DVCS, mais ne pas utiliser de base de données le rend extrêmement portable. Je peux copier mon arborescence source sur une clé USB et la réutiliser sur n'importe quelle machine, sans avoir à configurer un processus de serveur de base de données.

En ce qui corrompt pendant commits, VCS utilise les mêmes techniques exactes que les bases de données pour empêcher l' accès simultané, les transactions atomiques make, etc. corruptions dans les deux sont très rares, mais ils ne se produise . À toutes fins utiles, un magasin de données VCS est une base de données.

— Karl Bielefeldt
source

1

"correspond très mal aux bases de données" Pourtant, Vault et TFS font exactement cela. "L'intégrité des données n'est pas la seule préoccupation d'un VCS, ils sont également concernés par l'intégrité de l'historique des versions, pour lesquelles les bases de données ne sont pas très bonnes." Je ne vois pas comment le stockage de l'historique des versions se prête à des fichiers sur une base de données, d'autant plus que j'ai nommé des produits qui font exactement cela. ". Les corruption dans les deux cas sont très rares, mais elles se produisent." Aucun de ces résultats dans la première page ne parle de corruption de la base de données du serveur Vault. Le seul lien qui parle même du logiciel Vault est que le WC a été corrompu.

— Andy

"À toutes fins utiles, un magasin de données VCS est une base de données." Eh bien ... c'est mon point. Pourquoi ne pas simplement coller les données dans un véritable système de base de données au lieu de rouler les vôtres?

— Andy

2

@Andy Oui, c'est une base de données, mais toutes les bases de données ne sont pas substituables les unes aux autres. Chaque base de données a une certaine vision du monde (par exemple, les bases de données SQL implémentent essentiellement le modèle relationnel). Comme cette réponse détaille, les données qu'un VCS stocke et la façon dont les données sont utilisées ne correspondent pas au modèle relationnel. Je ne sais pas si certains db NoSQL font mieux, mais ils sont plutôt nouveaux et doivent encore prouver leur supériorité (je me souviens de rapports de graves problèmes d'intégrité pour certains). Et puis il y a toutes les autres questions en plus de cela.

Les DAG ne sont utilisés que dans DVCS (sauf si vous considérez un historique linéaire comme un DAG exceptionnellement simple, ce qui est le cas, mais ce n'est pas vraiment une abstraction utile.) Lorsque votre historique est linéaire, avec des ensembles de modifications augmentant de façon monotone, une base de données SQL a beaucoup plus de sens .

— Edward Thomson

L'augmentation monotone des numéros de version n'a pas beaucoup de sens pour les VCS. J'en ai utilisé un bon nombre, et ceux avec des numéros de version centralisés (CVS et SVN étant les 2 que je connais le mieux) ont tendance à être difficiles à fusionner. Et même ceux-ci utilisent des DAG lorsqu'ils tentent de fusionner. Ce n'est pas parce que leur représentation de stockage n'est pas basée sur elle qu'elle n'est pas utilisée.

— Mike Larsen

2

Meilleure reprise après sinistre (pire scénario: nous l'analyserons à l'œil nu, comme autrefois)
Faciliter le suivi et le débogage de ces catastrophes, éventuellement causées par des défaillances du système VCS.
Réduire le nombre de dépendances. (n'oublions pas que l'un de ces systèmes gère le noyau et que l'autre était censé le faire)
Un éditeur de texte est toujours disponible. (Licences MS SQL Server ... pas tellement)

— ZJR
source

Cette réponse est tout simplement mauvaise. Le seul point vraiment vrai est la diminution du nombre de dépendances. Les deux systèmes de support doivent être à la hauteur car vous devez effectuer des sauvegardes appropriées, le débogage des applications DB n'est pas plus difficile que le débogage des applications qui écrivent des fichiers et l'éditeur de texte est toujours disponible? Je ne sais même pas quel est votre point de vue, car le VCS ne va pas lui-même utiliser un éditeur de texte, et il existe d'autres serveurs de base de données (Sqlite, Postgre, MySql, etc.) de sorte que si vous vouliez un Le manque de solution d'un serveur db sur une solution soutenue par db ne devrait pas être un facteur.

— Andy

1

@Andy ... les programmeurs vont utiliser un éditeur de texte. Vous savez, l'édition de texte est toujours disponible comme fonction secondaire, même dans votre IDE préféré.

— ZJR

1

@Andy sqliteest la seule alternative possible aux fichiers texte, étant donné la grande quantité de scénarios distribués que DVCS modernes servent. (idk, peut-être que vous avez peut-être manqué la partie "distribuée" de DVCS) Tout le reste serait trop lourd (configuration + pare-feu + licence) ou même idiot pour être distribué . Ensuite, faire un scénario post-mortem pire scénario à un sqlite pourrait s'avérer difficile.

— ZJR

1

@ZJR: Je ne pense pas que la question d'origine ait jamais spécifié le contrôle de version distribué, elle portait sur les systèmes de contrôle de version en général. De plus, votre argument de l'éditeur de texte est un peu plat, car de nombreux systèmes ne stockent pas uniquement des fichiers texte plats. Même git possède de nombreux formats de fichiers binaires (objets lâches, fichiers pack, etc.) qui rendent votre éditeur de texte inutile.

— Edward Thomson

@ZJR En quoi la modification du code dans un éditeur de texte est-elle pertinente pour le magasin de sauvegarde d'un VCS? Suggérez-vous une modification manuelle, par exemple la base de données de SVN? De plus, ma question ne se limite pas au DVCS, donc je ne sais pas pourquoi vous en faites autant.

— Andy

2

Fossil est un excellent système de contrôle de version distribué (DVCS) et utilise SQLite pour le stockage, pas de fichiers en texte brut.

J'aime vraiment qu'il ait intégré: le suivi des bogues, le Wiki et qu'il soit vraiment distribué. Je veux dire que vous pouvez vraiment travailler hors ligne et corriger des bugs.

Fossil utilise Sqlite comme format de fichier d'application. Dans la keynote de PgCon, le Dr Richard Hipp explique quels sont les avantages de l'utilisation de sqlite comme système de fichiers d'application et fait un argument assez convaincant sur les avantages de l'utilisation d'une base de données comme système de fichiers.

Le deuxième sujet principal était que SQLite devrait être considéré comme un format de fichier d'application - une alternative à l'invention de ses propres formats de fichier ou à l'utilisation de fichiers XML compressés. La déclaration «SQLite ne remplace pas PostgreSQL. SQLite remplace les clous fopen () »(diapositive 21). Enfin, Richard a mis l'accent sur le fait que SQLite s'occupe de vos données (crash crash, ACID) use-the-index.com

Le Dr Hipp a maintenant répondu aux préoccupations concernant la sauvegarde du code dans une base de données

Pourquoi Fossil est-il basé sur SQLite au lieu d'une base de données NoSQL distribuée?

Fossil n'est pas basé sur SQLite. L'implémentation actuelle de Fossil utilise SQLite comme magasin local pour le contenu de la base de données distribuée et comme cache pour les méta-informations sur la base de données distribuée qui sont précalculées pour une présentation rapide et facile. Mais l'utilisation de SQLite dans ce rôle est un détail d'implémentation et n'est pas fondamentale pour la conception. Une future version de Fossil pourrait supprimer SQLite et remplacer une pile de fichiers ou une base de données de clés / valeurs à la place de SQLite. (En fait, il est très peu probable que cela se produise car SQLite fonctionne incroyablement bien dans son rôle actuel, mais le fait est que l'omission de SQLite de Fossil est une possibilité théorique.)

— elviejo79
source