Op Ma, 25 januari, 2010 08:18, schreef Paul Serice:
On Sun, 2010-01-24 at 18:29 -0500, D. Richard Hipp wrote:
On Jan 24, 2010, at 5:42 PM, Paul Serice wrote:
Just search for Berkeley DB usage leading to respository
corruption and data loss on the Wikipedia page for Subversion.
That's why subversion switched to SQLite, isn't it?
They switched to pile-of-files as the default. They still have the
option to create Berkeley DB repositories. From their INSTALL file,
they use SQLite only internally which is probably a good thing because
they've given Berkeley DB quite a black eye; whether it's deserved or
not, I do not know.
At the end of the day sqlite is a pile of tables. It still has to manage
the enitities (artefacts, users,tickets, check-ins,...). But it
convenient hides the details from vision.
Sqlite has a good(I assume here I can neither prove or disprove) track
record for well maintaining its entities
I'm quit sure that file systems have a very good track record for
maintaining files. It is just those pesky little humans who screw up the
file systems :-)
It's storage and every storage organization form has its pros and cons.
What (I think) Richard is saying that Sqlite is just a convenient storage
module that has nothing to do with fossil's scm algorithm. It is just a
storage method he has chosen(not surprisingly him being the maker) . With
the consequence that there is one file for a scm project.
Would he have chosen Berkley DB then the storage would be different and
you loose the convenience of one file.
Other storage implementations bring more dependencies (think oracle,
mysql, postgres, Hsqldb, ) or would require to build storage
capabilities e.g. an other sqlite.
It is interesting to see that Linus for git has build his own storage
capabilities. From
http://www.software-configuration.com/articles/git-fast_version_control_system.html
-
A third matter that occasionally concerns people is the GIT storage model.
Each created item is retained in an individual file. In an attempt to use
space efficiently, these individual files are saved in a collective format
known as a pack. As history is created, it is stored in single files;
therefore packing into collective pack form is required periodically. This
is done automatically on occasion by the GIT system. However, using the
git-go command will enable you to process this manually whenever you
choose. This would prove useful to you if you have recently worked on a
large collection and wanted it efficiently stored as soon as possible,
prior to the automatic packing.
So git is just a pile of files and storage concerns are everywhere
--
Rene de Zwart
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
