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
