> Well, I am not too sure if this is the good thing to do, to put > tla on top of sqlite (or any database).
It is indeed a bad idea, a very bad one infact. I can elaborate if there is a need on this. > 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 Not true. You can make a union of the CD and the disk, and have all writes occur on the disk. Yes !! Completely agree with you. To implement the use of SQLite, we must add a new notion : backend notion. I disagree, strongly. TLA should not even have a notion of a backend. It should only need a notion of `file-system operations'. Then if you want to use SQL as your file-system, you simply mount it. Solutions like these are very short sighted. With this we can have an efficient DB backend, without modifying anything about the actual filesystem backend. You still end up modifying tla for the purpose, which is simply the wrong place to add such functionality. Sorry for the short response, got alot todo... If someone wants a more detailed explanation why adding _any_ kind of logic into tla/hackerlab/etc about different `backends' is a horribly horribly horrid idea, then I will with pleasure do so. _______________________________________________ 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/
