Aldrik KLEBER wrote: > tla don't touch the database directly, this is the SQLite engine who > access the database, SQLite engine is mature.
Let's just say that the probability of corrupting a database while working with it is much higher than probability of corrupting files while reading them. My trust in tla *and* sqlite and together is much smaller than my trust in tla only (or sqlite only), not because sqlite is not good, but because my trust (lower than 100% multiplies) with each. In fact, I would like to see tla make revision directories/files read/only right after creation. Maybe one day I add such thing to tla... Milan. > Le Lundi 09 Janvier 2006 16:23, Milan Cvetkovic a écrit : > >>Andy Tai wrote: >> >>>Thanks for the information. It does not look like this is an easy thing >>>to do, to try to put a tla archive on top of sqlite. But nontheless I >>>may try to look into continuing the work you have done when I feel up to >>>it... >> >>Well, I am not too sure if this is the good thing to do, to put tla on >>top of sqlite (or any database). >> >>One of the main reasons why I decided to use tla (and migrate all >>projects in the company to tla) is that it *never* touches the old files >>(old revisions). So, you could have portions of your archive on a CD >>ROM. > > You can't have a part of an archive on CD, and the other part on the hard > disk, you need to mirror the archive on CD to hardisk > > >>I never tried this, but the thought of "not modifying" the previous >>revisions gave me high level of confidence that tla will not corrupt my >>archive so easy. >> > > It is not so easy to corrupt a database, sqlite is a transactionnal database. > > >>With sqlite, I would imagine that there would be a single database for a >>number of revisions. Adding a revision would have to modify this >>database, rather than add a new file (or directory, or whatever tla >>adds). This means that a bug in tla could easyly corrupt old revisions. >> > > tla don't touch the database directly, this is the SQLite engine who access > the database, SQLite engine is mature. > > >>At least, there should be always be an option to use file system instead >>of sqlite. >> > > > Yes !! Completely agree with you. > To implement the use of SQLite, we must add a new notion : backend notion. > archive and revision library should be able to switch freely between a > filesystem backend and a DB backend. > > With this we can have an efficient DB backend, without modifying anything > about the actual filesystem backend. > > And because the notion of backend is independant if the implementation we > solve the problem of trying to manage a virtual filesystem, wich is not a > good approach. > > > >>Regards, Milan. >> _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
