(Illustration by Gaich Muramatsu)
>>>>> "Jan" == Jan Harkes <jaharkes_at_cs.cmu.edu> writes: Jan> Argh, libdb4, they are at 4 already? What is the use of a Jan> 'data storage' if it changes about twice a year. Does anyone Jan> think it is reasonable to expect to read a database file that Jan> was created less than 2 years ago? AFAIK libdb4 _is_ backward-compatible with everything since libdb2 at the file format level. They've added two new access/indexing schemes (IIRC) and also changed the database opening call in a trivial way (they added a couple of parameters which when defaulted to NULL work as in previous versions) which justifies the major version bumps. They are not forward compatible, you must rebuild old apps to use the new access/index formats. (Again, IIRC) the reason for the file format incompatibility 1.85 -> 2 was to provide backward compatibility of this kind in the future (not to mention sane error messages when an unknown format is ecnountered). The 1.85 format didn't provide for future extension, guaranteeing the kind of pain Coda is experiencing now. Hard on you (and me!) but I think Sleepycat did the best they could. It does rather anger me that Debian and (apparently) Red Hat fail to go to the trouble to create a db_dump185 that can read 1.85-format files (AFAICT Debian's default db_dump185 is just a regular DB3 db_dump that can only read DB2 files ;-). -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.Received on 2002-12-24 01:32:02