¿Por qué los sistemas de control de código fuente aún están respaldados principalmente con archivos?

22

Parece que más sistemas de control de código fuente todavía usan archivos como medio para almacenar los datos de la versión. Vault y TFS usan Sql Server como su almacén de datos, lo que creo que sería mejor para la consistencia de los datos y la velocidad.

Entonces, ¿por qué SVN, creo que GIT, CVS, etc. todavía usan el sistema de archivos como esencialmente una base de datos (hago esta pregunta porque nuestro servidor SVN simplemente se corrompió durante una confirmación normal) en lugar de usar el software de base de datos real ( MSSQL, Oracle, Postgre, etc.

EDITAR: Creo que otra forma de hacer mi pregunta es "¿por qué los desarrolladores de VCS implementan su propio sistema de almacenamiento de datos estructurado en lugar de utilizar uno existente?"

version-control Andy
fuente
29
¿Qué crees que la mayoría de las bases de datos usan como respaldo básico? La mayoría usa archivos (sin embargo, algunos usan acceso directo a discos duros). Puede tener todas las características de una base de datos utilizando "solo archivos".
Joachim Sauer el
2
@JoachimSauer Fair point, aunque por supuesto tendrías que crear una base de datos tú mismo entonces. Lo cual es una tontería si su conjunto de características deseado está cerca de las soluciones existentes y no tiene muy buenas razones para no usar ninguna de ellas.
1
@JoachimSauer Sí, me doy cuenta de eso, pero los sistemas DBM tienen formas de garantizar que nada inconsistente entre en la base de datos. A menos que estos repositorios basados ​​en archivos estén usando algo como NTSF transaccional, todavía existe la posibilidad de que se corrompa. Y confío más en una base de datos real que en un conjunto de desarrolladores que esencialmente reinventan la rueda, ya que creo que podemos estar de acuerdo en que los sistemas de control de origen requieren integridad de datos.
Andy
2
@delnan Soporte transaccional y consistencia interna. Ahora estamos restaurando nuestro repositorio SVN desde la cinta b / c, el servidor SVN no escribió correctamente en todos los archivos que se suponía. También busca grandes volúmenes de datos. Mi punto es, ¿por qué intentar reinventar la rueda?
Andy
77
Cada sistema operativo principal viene con un sistema de archivos incorporado. Todos estos sistemas de archivos tienen la misma funcionalidad básica (archivos, carpetas, persistencia de los mismos). Básicamente, una base de datos es una dependencia adicional que el usuario final necesita instalar y mantener actualizada. El control de origen no es el negocio principal de la mayoría de las personas (a menos que sea sourceforge o github). VC a menudo se instala en los servidores a través de la línea de comando por el miembro más nuevo del equipo. La facilidad de instalación y configuración es importante.
GlenPeterson el

Respuestas:

23

TL; DR: Pocos sistemas de control de versiones usan una base de datos porque no es necesaria.

Como pregunta por respuesta, ¿por qué no lo harían? ¿Qué beneficios ofrecen los sistemas de bases de datos "reales" sobre un sistema de archivos en este contexto?

Tenga en cuenta que el control de revisión consiste principalmente en realizar un seguimiento de unos pequeños metadatos y una gran cantidad de diferencias de texto. El texto no se almacena en las bases de datos de manera más eficiente, y la indexabilidad de los contenidos no será un factor.

Supongamos que Git (por el bien del argumento) usó un BDB o SQLite DB para su back-end para almacenar datos. ¿Qué sería más confiable sobre eso? Cualquier cosa que pueda dañar archivos simples también puede dañar la base de datos (ya que también es un archivo simple con una codificación más compleja).

Desde el paradigma del programador de no optimizar a menos que sea necesario, si el sistema de control de revisión es lo suficientemente rápido y funciona de manera confiable, ¿por qué cambiar todo el diseño para utilizar un sistema más complejo?

mikebabcock
fuente
2
TLDR? ¡Su respuesta fue el doble de larga y la pregunta fue muy breve!
Brad
25
@Brad Las tres palabras que siguen TL;DRson la versión resumida de las respuestas, no una declaración de que la pregunta es demasiado larga y que no la leyó antes de responder.
66
@Andy Mercurial también tiene "grep en la historia", y es probable que git también lo tenga. También es muy rápido. En cuanto a dejar las cosas a expertos: las personas que desarrollan VCS son expertos.
3
Solo quiero agregar que sí entiendo tu punto; si VCS escribe datos incorrectos, no importa si está escribiendo esos datos en un archivo o base de datos. La otra cara es que los repositorios basados ​​en archivos probablemente están escribiendo en más de un archivo a la vez y normalmente no hay soporte transaccional para eso, por lo que si un archivo escribe pero otro falla, su VCS ahora está dañado, frente a múltiples tablas escritas dentro de una base de datos la transacción se comprometerá para fallar como unidad. Siento que un grupo de desarrolladores que crean software de base de datos tiene más experiencia con esto que las personas que escriben SVN ... pero tal vez me equivoque.
Andy
66
Su elección de git "por el bien del argumento" es un punto importante aquí: git tiene un muy buen modelo para escribir sus objetos, pero muchas herramientas no. Con git, si la computadora se apaga en medio de una confirmación, habrá escrito algunos de los objetos en el sistema de archivos y simplemente serán inalcanzables. Con otros VCS, es posible que haya agregado los cambios a la mitad de los archivos (y se produce confusión). Podría argumentar que otras herramientas de control de versiones están mal diseñadas (y tendría razón), pero cuando está escribiendo un VCS, es es mucho más fácil usar una transacción SQL y dejar que haga lo correcto.
Edward Thomson el
25

Parece que está haciendo muchas suposiciones, posiblemente basadas en su experiencia con SVN y CVS.

Git y Mercurial son básicamente como SVN y CVS

Comparar git y CVS es como comparar un iPad y un Atari. CVS fue creado cuando los dinosaurios vagaban por la Tierra . Subversion es básicamente una versión mejorada de CVS. Asumir que los sistemas modernos de control de versiones como git y Mercurial funcionan como ellos tiene muy poco sentido.

Una base de datos relacional es más eficiente que una base de datos de un solo propósito.

¿Por qué? Las bases de datos relacionales son realmente complicadas y pueden no ser tan eficientes como las bases de datos de propósito único. Algunas diferencias en la parte superior de mi cabeza:

  • Los sistemas de control de versiones no necesitan un bloqueo complicado, ya que de todos modos no puede realizar múltiples confirmaciones al mismo tiempo.
  • Los sistemas de control de versiones distribuidos deben ser extremadamente eficientes en cuanto al espacio, ya que la base de datos local es una copia completa del repositorio.
  • Los sistemas de control de versiones solo necesitan buscar datos de un par de formas específicas (por autor, por ID de revisión, a veces búsqueda de texto completo). Hacer su propia base de datos que pueda manejar búsquedas de ID de autor / revisión es trivial y las búsquedas de texto completo no son muy rápidas en ninguna base de datos relacional que he probado.
  • Los sistemas de control de versiones deben funcionar en múltiples plataformas. Esto dificulta el uso de una base de datos que debe instalarse y ejecutarse como un servicio (como MySQL o PostgreSQL).
  • Los sistemas de control de versiones en su máquina local solo necesitan ejecutarse cuando está haciendo algo (como un commit). Dejar un servicio como MySQL ejecutándose todo el tiempo en caso de que desee realizar una confirmación es un desperdicio.
  • En su mayor parte, los sistemas de control de versiones nunca quieren eliminar el historial, solo añádelo. Eso puede conducir a diferentes optimizaciones y diferentes métodos de protección de la integridad.

Las bases de datos relacionales son más seguras

De nuevo por qué? Parece suponer que debido a que los datos se almacenan en archivos, los sistemas de control de versiones como git y Mercurial no tienen compromisos atómicos , pero los tienen. Las bases de datos relacionales también almacenan sus bases de datos como archivos. Es notable aquí que CVS no realiza confirmaciones atómicas, pero eso es probablemente porque es de la Edad Media, no porque no usen bases de datos relacionales.

También está el problema de proteger los datos de la corrupción una vez que están en la base de datos, y nuevamente la respuesta es la misma. Si el sistema de archivos está dañado, no importa qué base de datos esté usando. Si el sistema de archivos no está dañado, entonces su motor de base de datos podría estar dañado. No veo por qué una base de datos de control de versiones sería más propensa a esto que una base de datos relacional.

Yo diría que los sistemas de control de versiones distribuidos (como git y Mercurial) son mejores para proteger su base de datos que el control de versiones centralizado, ya que puede restaurar todo el repositorio desde cualquier clon. Por lo tanto, si su servidor central se quema espontáneamente, junto con todas sus copias de seguridad, puede restaurarlo ejecutándose git initen el nuevo servidor, y luego git pushdesde la máquina de cualquier desarrollador .

Reinventar la rueda es malo

El hecho de que pueda usar una base de datos relacional para cualquier problema de almacenamiento no significa que deba hacerlo . ¿Por qué utiliza archivos de configuración en lugar de una base de datos relacional? ¿Por qué almacenar imágenes en el sistema de archivos cuando podría almacenar los datos en una base de datos relacional? ¿Por qué mantener su código en el sistema de archivos cuando podría almacenarlo todo en una base de datos relacional?

"Si todo lo que tienes es un martillo, todo parece un clavo".

También existe el hecho de que los proyectos de código abierto pueden permitirse reinventar la rueda siempre que sea conveniente, ya que no tiene los mismos tipos de limitaciones de recursos que los proyectos comerciales. Si tiene un voluntario experto en escribir bases de datos, ¿por qué no usarlo?

En cuanto a por qué confiaríamos en los escritores de sistemas de control de revisiones para saber lo que están haciendo ... No puedo hablar por otros VCS, pero estoy bastante seguro de que Linus Torvalds entiende los sistemas de archivos .

¿Por qué algunos sistemas de control de versiones comerciales usan una base de datos relacional entonces?

Lo más probable es una combinación de lo siguiente:

  • Algunos desarrolladores no quieren escribir bases de datos.
  • Los desarrolladores de sistemas de control de versiones comerciales tienen limitaciones de tiempo y recursos, por lo que no pueden darse el lujo de escribir una base de datos cuando ya tienen algo cercano a lo que quieren. Además, los desarrolladores son caros, y los desarrolladores de bases de datos (como en las personas que escriben bases de datos) son probablemente más caros, ya que la mayoría de las personas no tienen ese tipo de experiencia.
  • Los usuarios de sistemas de control de versiones comerciales tienen menos probabilidades de preocuparse por la sobrecarga de configurar y ejecutar una base de datos relacional, ya que ya tienen una.
  • Es más probable que los usuarios de sistemas de control de versiones comerciales deseen una base de datos relacional que respalde sus datos de revisión, ya que esto puede integrarse mejor con sus procesos (como las copias de seguridad, por ejemplo).
Reinstalar a Mónica
fuente
1
Una cosa: los commits de SVN son atómicos. De hecho, es un importante punto de venta (o al menos lo fue, cuando tuvieron que convencer a los usuarios de CSV para que cambiaran).
1
@delnan - Tenga en cuenta que existe una gran diferencia entre la atomicidad teórica que obtiene con los svndiferentes directorios en su directorio de trabajo pueden estar en diferentes svnrevisiones y la verdadera atomicidad amplia del repositorio que obtiene con gito hg.
Mark Booth
2
@Andy Y mi punto es que puedes manejar exactamente esos mismos escenarios sin una base de datos relacional completa. Si dos personas se comprometen exactamente al mismo tiempo, el servidor puede hacer una tras otra. Esa no es una característica complicada de implementar. Si desea hacer eso con un usuario local, solo tenga un archivo de bloqueo. Cuando comience una confirmación, obtenga un bloqueo en el archivo. Cuando finalice una confirmación, libere el bloqueo. Si desea permitir confirmaciones en varias ramas a la vez, use un archivo de bloqueo para cada rama. Claro, SQLite haría esto por mí, pero no es necesario .
Mónica el
1
Del mismo modo, implementar un diario básico tampoco es complicado. (1) Escriba la nueva confirmación en un archivo. (2) Copie el antiguo archivo de índice. (3) Escribir un nuevo archivo de índice. (4) Elimine la copia del antiguo archivo de índice. Si falla en los pasos 1, 2 o 4, solo necesita limpiar los nuevos archivos que creó. Si falla en el paso 3, solo necesita volver a copiar el archivo de índice anterior. Alguien que comprenda mejor los sistemas de archivos probablemente podría hacer una versión mucho más eficiente de esto, pero siempre puede hacer referencia al código fuente de SQLite si lo necesita (es de dominio público).
Vuelva a instalar Mónica el
1
@BrendanLong Grandes puntos. Agradezco la discusión. Para ser claros, creo que hay ventajas y desventajas para ambos tipos de tiendas de respaldo, no creo que haya una sola respuesta correcta. Sin embargo, me sorprendió un poco, parece que solo hay tres (cuatro si cuenta Vault y Vercity por separado) que usan SQL y la gran mayoría no, eso es todo.
Andy
18

Realmente svnsolía usar BDB para repositorios. Esto finalmente se eliminó porque era propenso a la rotura.

Otro VCS que actualmente usa un DB (SQLite) es fossil. También integra un rastreador de errores.

Supongo que la verdadera razón es que los VCS funcionan con muchos archivos. Los sistemas de archivos son solo otro tipo de base de datos (jerárquica, enfocada en la eficiencia de almacenamiento CLOB / BLOB). Las bases de datos normales no se manejan tan bien porque no hay razón para hacerlo, ya existen sistemas de archivos.

Mike Larsen
fuente
1
BDB no contaría exactamente como confiable, como SQLite es una base de datos en proceso. Dicho esto, creo que la confiabilidad de Oracle / MSSQL / MySQL / Postgres, dependiendo de cómo los configure, no es muy diferente de los sistemas de archivos. El principal problema es que los RDBMS no están diseñados para las estructuras jerárquicas y gráficas con las que comúnmente trabajan los VCS. Y en ese caso, los sistemas de archivos simplemente ganan.
Mike Larsen
3
@Andy: Fossil fue creado por el creador de SQLite. No es realmente tan sorprendente :-)
Jörg W Mittag
1
@Andy: confiaría en SQLite mucho más que Oracle o MSSQL. No es de extrañar que sea la base de datos SQL más utilizada, por un amplio margen. También es el portado a la mayoría de las arquitecturas diferentes, cada una con su propio conjunto de desafíos, lo que hace que el código compartido sea increíblemente a prueba de balas.
Javier
1
@Javier No confiaría tanto en Sqlite como en MSSQL u Oracle; como dijo Mike, la parte en proceso me da miedo, como si su aplicación se muriera, lo que podría dejar su base de datos corrupta ahora. Con una base de datos de cliente / servidor, el cliente que muere anula la transacción. No quiere decir que sea imposible que los CS DB se corrompan, pero creo que es menos probable que tener el motor DB combinado con la aplicación.
Andy
55
@Andy, para eso están las transacciones. No importa en qué momento elimine un buen motor de base de datos, una transacción determinada se confirma o no. La implementación de SQLite de confirmaciones atómicas ( sqlite.org/atomiccommit.html ) es particularmente sofisticada.
Javier
10

  1. Un sistema de archivos es una base de datos. No es una base de datos relacional, por supuesto, pero la mayoría son almacenes de clave / valor muy eficientes. Y si sus patrones de acceso están bien diseñados para un almacén de valores clave (por ejemplo, el formato de repositorio git), el uso de una base de datos probablemente no ofrezca ventajas significativas sobre el uso del sistema de archivos. (De hecho, es solo otra capa de abstracción que se interpone).

  2. Muchas de las características de la base de datos son solo equipaje adicional. ¿Búsqueda de texto completo? ¿La búsqueda de texto completo tiene sentido para el código fuente? ¿O necesita tokenizarlo de manera diferente? Esto también requiere que almacene archivos completos en cada revisión, lo cual es poco común. Muchos sistemas de control de versiones almacenan deltas entre revisiones del mismo archivo para ahorrar espacio, por ejemplo, Subversion y Git (al menos, cuando se usan archivos de paquete).

  3. Los requisitos multiplataforma hacen que el uso de una base de datos sea más desafiante.

    La mayoría de las herramientas de control de versiones están diseñadas para ejecutarse en múltiples plataformas. Para las herramientas de control de versiones centralizadas, esto solo afecta al componente del servidor, pero aún es difícil confiar en un único servidor de base de datos ya que los usuarios de Unix no pueden instalar Microsoft SQL Server y los usuarios de Windows pueden no estar dispuestos a instalar PostgreSQL o MySQL. El sistema de archivos es el mínimo común denominador. Sin embargo, hay varias herramientas en las que el servidor debe instalarse en una máquina con Windows y, por lo tanto, requieren SQL Server, por ejemplo, SourceGear Vault y Microsoft Team Foundation Server .

    Los sistemas de control de versiones distribuidos hacen que esto sea aún más desafiante, ya que cada usuario obtiene una copia del repositorio. Esto significa que cada usuario necesita una base de datos para colocar el repositorio. Esto implica que el software:

    1. Está limitado a un subconjunto de plataformas donde existe una base de datos particular
    2. Apunta a un único servidor de base de datos que es multiplataforma (por ejemplo, SQLite).
    3. Apunta a un backend de almacenamiento conectable, para que uno pueda usar cualquier base de datos que desee (posiblemente incluyendo el sistema de archivos).

    La mayoría de los sistemas de control de versiones distribuidos, por lo tanto, solo usan el sistema de archivos. Una notable excepción es SourceGear's Veracity , que puede almacenarse en una base de datos SQLite (útil para repositorios locales) o una base de datos relacional como SQL Server (posiblemente útil para un servidor). Su oferta alojada en la nube puede usar un back-end de almacenamiento no relacional como Amazon SimpleDB , pero no sé que esto sea cierto.

Edward Thomson
fuente
Tal como el comentario de un defensor del diablo quizás, la mayoría de las personas que hacen este tipo de preguntas de "por qué no usar una base de datos" parecen significar "¿por qué no usar un RDBMS?" con todo el cumplimiento de ACID y otros asuntos involucrados. El hecho de que todos los sistemas de archivos ya sean bases de datos propias ya ha sido descartado.
mikebabcock
6

Por lo que he visto en muchas ofertas, parece que los archivos son "lo suficientemente buenos" para el trabajo, algo razonable, teniendo en cuenta que, al final del día, la salida de VCSes también son archivos.

Hay muchas compañías que ofrecen un back-end RDBMS con una interfaz svn / git / etc, por lo que lo que está pidiendo ya existe.

Dimitrios Mistriotis
fuente
5

Diría que es porque la estructura de datos primaria de un sistema de control de versiones es un DAG, que se asigna muy mal a las bases de datos. Muchos de los datos también son direccionables por contenido, lo que también se asigna muy mal a las bases de datos.

La integridad de los datos no es la única preocupación de un VCS, también se preocupan por la integridad del historial de versiones , en las cuales las bases de datos no son muy buenas. En otras palabras, cuando recupera una versión, no solo necesita asegurarse de que la versión no tenga fallas actuales, sino también que nada en toda su historia ha sido alterado subrepticiamente.

Los VCS también son un producto de consumo además de un producto empresarial. La gente los usa en pequeños proyectos de pasatiempos de un solo hombre. Si agrega la molestia de instalar y configurar un servidor de base de datos, va a alienar gran parte de esa parte del mercado. Supongo que no ves muchas instalaciones de Vault y TFS en casa. Es la misma razón por la que las hojas de cálculo y los procesadores de texto no usan bases de datos.

Además, esta es una razón más para DVCS, pero no usar una base de datos lo hace extremadamente portátil. Puedo copiar mi árbol de origen en una memoria USB y reutilizarlo en cualquier máquina, sin tener que configurar un proceso de servidor de base de datos.

En lo que a corromper durante confirmaciones, VCS utiliza exactamente las mismas técnicas que las bases de datos para evitar el acceso simultáneo, maquillaje transacciones atómicas, etc. corrupciones en ambos son muy raros, pero no sucede . Para todos los efectos, un almacén de datos VCS es una base de datos.

Karl Bielefeldt
fuente
1
"se asigna muy mal a las bases de datos" Sin embargo, Vault y TFS hacen exactamente esto. "La integridad de los datos no es la única preocupación de un VCS, también les preocupa la integridad del historial de versiones, en las cuales las bases de datos no son muy buenas". No veo cómo almacenar el historial de versiones se presta en archivos a través de una base de datos, especialmente porque he nombrado productos que hacen exactamente eso. ". Las corrupciones en ambos son muy raras, pero suceden". Ninguno de esos resultados en la primera página habla sobre la corrupción de la base de datos del servidor Vault. El único enlace que incluso habla sobre el software Vault es que el WC se corrompió.
Andy
"Para todos los efectos, un almacén de datos VCS es una base de datos". Bueno ... ese es mi punto. ¿Por qué no simplemente pegar los datos en un sistema de base de datos real en lugar de rodar los suyos?
Andy
2
@Andy Sí, es una base de datos, pero no todas las bases de datos son sustituibles entre sí. Cada base de datos tiene una visión determinada del mundo (por ejemplo, las bases de datos SQL básicamente implementan el modelo relacional). Como se detalla en esta respuesta, los datos que almacena un VCS y la forma en que se usan los datos no se ajustan al modelo relacional. No estoy seguro de si algunos db NoSQL funcionan mejor, pero son bastante nuevos y aún no han demostrado su superioridad (recuerdo los informes de problemas de integridad graves para algunos). Y luego están todos los otros problemas además de eso.
Los DAG solo se usan en DVCS (a menos que considere un historial lineal como un DAG excepcionalmente simple, lo cual es, pero eso no es realmente una abstracción útil). Cuando su historial es lineal, con conjuntos de cambios monotónicamente crecientes, una base de datos SQL tiene mucho más sentido .
Edward Thomson el
Los números de versión que aumentan monotónicamente no tienen mucho sentido para los VCS. He usado un buen número de ellos, y los que tienen números de versión centralizados (CVS y SVN son los 2 con los que estoy más familiarizado) tienden a ser difíciles de combinar. E incluso aquellos usan DAG cuando intentan fusionarse. El hecho de que su representación de almacenamiento no se base en eso no significa que no se use.
Mike Larsen
2

  • Mejor recuperación ante desastres (peor de los casos: lo analizaremos a simple vista, como en los viejos tiempos)

  • Hacer más fácil el seguimiento y la depuración de tales desastres, posiblemente causados ​​por fallas en el sistema VCS.

  • Bajar el número de dependencias. (no olvidemos que uno de esos sistemas está manejando el kernel, y se suponía que el otro debía hacerlo)

  • Un editor de texto siempre está disponible. (Licencias de MS SQL Server ... no tanto)

ZJR
fuente
Esta respuesta es simplemente mala. El único punto realmente verdadero es reducir el número de dependencias. Ambos sistemas de respaldo deben estar a la par, ya que debería estar haciendo copias de seguridad adecuadas, depurar aplicaciones de base de datos no es más difícil que depurar aplicaciones que escriben archivos, y el editor de texto siempre está disponible. Ni siquiera sé cuál es su punto, ya que el VCS no va a utilizar un editor de texto, y hay otros servidores de bases de datos (Sqlite, Postgre, MySql, etc.), de modo que si DESEA la solución respaldada por db la falta de un servidor db no debería ser un factor.
Andy
1
@Andy ... los programadores lo usarán para usar un editor de texto. Ya sabes, la edición de texto todavía está disponible como una función secundaria, incluso en tu IDE favorito.
ZJR
1
@Andy sqlitees la única alternativa posible a los archivos de texto, dada la gran cantidad de escenarios distribuidos que sirven los DVCS modernos. (idk, tal vez te hayas perdido la parte "distribuida" de DVCS) Cualquier otra cosa sería demasiado engorrosa (configuración + firewall + licencia) o incluso tonta para ser distribuida . Entonces, una vez más, hacer el peor de los casos postmortem a un sqlite podría resultar difícil.
ZJR
1
@ZJR: No creo que la pregunta original nunca se especifica el control de versiones distribuido, se le preguntó acerca de los sistemas de control de versiones en general. Además, su argumento del editor de texto es un poco plano, ya que muchos sistemas no almacenan solo archivos de texto plano. Incluso git tiene muchos formatos de archivos binarios (objetos sueltos, paquetes de archivos, etc.) que hacen que su editor de texto sea inútil.
Edward Thomson el
@ZJR ¿Cómo es que la edición de código en un editor de texto es relevante para el almacén de respaldo de un VCS? ¿Está sugiriendo editar manualmente, digamos la base de datos de SVN? Además, mi pregunta no se limita a DVCS, por lo que no sé por qué estás insistiendo.
Andy
2

Fossil es un excelente Sistema de control de versiones distribuido (DVCS) y utiliza SQLite para el almacenamiento, sin archivos de texto sin formato.

Realmente me gusta que haya integrado: seguimiento de errores, Wiki y que esté realmente distribuido. Quiero decir que realmente puedes trabajar sin conexión y corregir errores.

Fossil usa Sqlite como su formato de archivo de aplicación. En la conferencia magistral de PgCon, el Dr. Richard Hipp explica cuáles son las ventajas de usar sqlite como un Sistema de archivos de aplicación, y hace un argumento bastante convincente sobre los beneficios de usar una base de datos como sistema de archivos.

El segundo tema principal fue que SQLite debería ser visto como un formato de archivo de aplicación, una alternativa a la invención de formatos de archivo propios o al uso de XML comprimido. La declaración "SQLite no es un reemplazo para PostgreSQL. SQLite es un reemplazo para clavos fopen () ”que (diapositiva 21). Finalmente, Richard puso mucho énfasis en el hecho de que SQLite se encarga de sus datos (a prueba de choques, ACID) use-the-index.com

Ahora el Dr. Hipp ha abordado las inquietudes sobre guardar código en una base de datos

  • ¿Por qué Fossil se basa en SQLite en lugar de una base de datos NoSQL distribuida?

Fossil no está basado en SQLite. La implementación actual de Fossil utiliza SQLite como un almacén local para el contenido de la base de datos distribuida y como caché para metainformación sobre la base de datos distribuida que se calcula previamente para una presentación rápida y fácil. Pero el uso de SQLite en este rol es un detalle de implementación y no es fundamental para el diseño. Algunas versiones futuras de Fossil podrían eliminar SQLite y sustituir una pila de archivos o una base de datos de clave / valor en lugar de SQLite. (En realidad, es poco probable que eso suceda ya que SQLite funciona increíblemente bien en su función actual, pero el punto es que omitir SQLite de Fossil es una posibilidad teórica).

elviejo79
fuente