{"thread":{"id":"5433","subject":"problem with git-cvsserver","startedAt":"2006-08-30T15:45:43Z","lastAt":"2006-09-01T07:05:59Z","messageCount":11,"participants":["aonghus","Johannes Schindelin","Junio C Hamano","Martin Langhoff","Marco Roeland"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26111","messageId":"44F5B2A7.8070501@gmail.com","threadId":"5433","inReplyTo":null,"subject":"problem with git-cvsserver","fromName":"aonghus","fromEmail":"thecolourblue@gmail.com","sentAt":"2006-08-30T15:45:43Z","receivedAt":"2006-08-30T15:45:43Z","isPatch":false,"sender":{"key":"thecolourblue@gmail.com","avatar":null},"body":"Hi,\n\nI am trying to use git-cvsserver and I have come across this error:\n\n $ cvs co -d project-master master\n\n install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 .) at (eval 7) line 3, line 14.\n\n Perhaps the DBD::SQLite perl module hasn't been fully installed,\n\n or perhaps the capitalisation of 'SQLite' isn't right.\n\n Available drivers: DBM, ExampleP, File, Pg, Proxy, Sponge, mysql.\n\n at /usr/bin/git-cvsserver line 2055\n\n cvs [checkout aborted]: end of file from server (consult above messages if any)\n\n\nThis is a debian testing/unstable machine with git, git-core, git-cvs \netc installed (with no problems):\n\n $ dpkg --list git-cvs\n\n ||/ Name Version Description\n\n +++-===============================-===============================-\n\n ii git-cvs 1.4.1.1-1 content addressable filesystem (cvs interoperability)\n\n\nAlso, the perl DBI modules are installed:\n\n $ dpkg --list libdbd-sqlite3-perl\n\n ||/ Name Version Description\n\n +++-===============================-===============================-\n\n ii libdbd-sqlite3-perl 1.12-1 Perl DBI driver with a self-contained RDBMS\n\n $ dpkg -S SQLite\n\n libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz\n\n libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm\n\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite\n\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs\n\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so\n\n\nAnyone know whats wrong? If its a problem somewhere else (eg. with \ndebian packaging), please point me there,\n\nthanks\n\na\n"},{"id":"26112","messageId":"Pine.LNX.4.63.0608301904360.28360@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5433","inReplyTo":"44F5B2A7.8070501@gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-30T17:07:32Z","receivedAt":"2006-08-30T17:07:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 Aug 2006, aonghus wrote:\n\n> install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC\n> contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8\n> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8\n> /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7\n> .) at (eval 7) line 3, line 14.\n>\n> [...]\n> \n> libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm\n\nHave you checked that /usr/share/perl5/DBD/SQLite.pm is actually there? \nBecause your perl does not think so.\n\nOTOH it could be that it only works when SQLite.pm is in \n/usr/lib/perl5/DBD/ (note the \"lib\" instead of \"share\"), because in my \n(working) setup, both the .pm and the .so are under /usr/lib/perl5/...\n\nHth,\nDscho\n"},{"id":"26114","messageId":"44F5D6F8.50307@gmail.com","threadId":"5433","inReplyTo":"Pine.LNX.4.63.0608301904360.28360@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: problem with git-cvsserver","fromName":"aonghus","fromEmail":"thecolourblue@gmail.com","sentAt":"2006-08-30T18:20:40Z","receivedAt":"2006-08-30T18:20:40Z","isPatch":false,"sender":{"key":"thecolourblue@gmail.com","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi,\n>\n> On Wed, 30 Aug 2006, aonghus wrote:\n>\n> \n>> install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC\n>> contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8\n>> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8\n>> /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7\n>> .) at (eval 7) line 3, line 14.\n>>\n>> [...]\n>>\n>> libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm\n>> \n>\n> Have you checked that /usr/share/perl5/DBD/SQLite.pm is actually there? \n> Because your perl does not think so.\n>\n> OTOH it could be that it only works when SQLite.pm is in \n> /usr/lib/perl5/DBD/ (note the \"lib\" instead of \"share\"), because in my \n> (working) setup, both the .pm and the .so are under /usr/lib/perl5/...\n>\n> Hth,\n> Dscho\n> \n\nHi,\n\nThanks for the reply, but I think the files are in the right place- here \nis what I have:\n\n $ dpkg -S SQLite\n libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz\n libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so\n\n\nand it really is there:\n\n $ ll /usr/share/perl5/DBD/SQLite.pm\n -rw-r--r-- 1 root root 16K Apr 18 16:20 /usr/share/perl5/DBD/SQLite.pm\n\n\nI don't know much about the perl SQLite package, but it seems that \ngit-cvsserver is not loading the correct module. The line 'use DBI;' \nseems to load only this module:\n\n 'DBI.pm' => '1.51 from /usr/lib/perl5/DBI.pm'\n\nDoes it need something else to load the SQLite module?\n\na\n"},{"id":"26115","messageId":"7vlkp6gh6e.fsf@assigned-by-dhcp.cox.net","threadId":"5433","inReplyTo":"44F5D6F8.50307@gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-30T19:24:57Z","receivedAt":"2006-08-30T19:24:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"aonghus writes:\n\n> I don't know much about the perl SQLite package, but it seems that\n> git-cvsserver is not loading the correct module. The line 'use DBI;'\n> seems to load only this module:\n>\n> 'DBI.pm' => '1.51 from /usr/lib/perl5/DBI.pm'\n>\n> Does it need something else to load the SQLite module?\n\nWhen things are properly installed, it should be enough to say\n'use DBI' upfront and then 'DBI->connect(\"dbi:Foo:...\")' should\nbe enough to use DBD::Foo backend of the DBI interface.\n\nI am on Debian etch plus some from testing and have these:\n\n perl (5.8.8-6.1)\n perl-base (5.8.8-6.1)\n libdbi-perl (1.51-2)\n libsqlite3-0 (3.3.7-1)\n libdbd-sqlite3-perl (1.12-1)\n\nDoes this work for you?\n\n-- >8 -- cut here -- >8 --\n#!/usr/bin/perl -w\nuse DBI;\nmy $dsn = 'dbi:SQLite:dbname=foo';\nmy $dbh = DBI->connect($dsn, '', '');\n-- 8< -- cut here -- 8< --\n\nIf not, does it work for you if you substitute $dsn with\n'dbi:mysql:dbname=test'? The error message you showed us in\nyour earlier message said mysql was one of the backend your DBI\nknows about while SQLite is not.\n\nThis did not work for me before installing libdbd-sqlite3-perl\nand gave a very similar error message as you had.\n\nWhat's puzzling is that you said you have these:\n\n $ dpkg -S SQLite\n libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz\n libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs\n libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so\n\nbut that is exactly what I am seeing _after_ installing\nlibdbd-sqlite3-perl.\n"},{"id":"26116","messageId":"46a038f90608301329n14df4dd2tb1563cc48662cd14@mail.gmail.com","threadId":"5433","inReplyTo":"7vlkp6gh6e.fsf@assigned-by-dhcp.cox.net","subject":"Re: problem with git-cvsserver","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-08-30T20:29:21Z","receivedAt":"2006-08-30T20:29:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/31/06, Junio C Hamano wrote:\n\n> I am on Debian etch plus some from testing and have these:\n>\n> perl (5.8.8-6.1)\n> perl-base (5.8.8-6.1)\n> libdbi-perl (1.51-2)\n> libsqlite3-0 (3.3.7-1)\n> libdbd-sqlite3-perl (1.12-1)\n>\n> Does this work for you?\n>\n> -- >8 -- cut here -- >8 --\n> #!/usr/bin/perl -w\n> use DBI;\n> my $dsn = 'dbi:SQLite:dbname=foo';\n> my $dbh = DBI->connect($dsn, '', '');\n> -- 8< -- cut here -- 8< --\n\nHi! all this seems to have happened during NZ's night, so I'm only\ncatching up. +1 on all the diagnosis Junio is proposing. Can't think\nof anything more relevant to add. The code was developed mainly on a\nbunch of debian sarge/etch boxes using all the standard\nlibdbd-sqlite-perl libs, and a gentoo box.\n\nActually, just looking at my etch dev box, libdbd-sqlite-perl is\n0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is\nsignificant. Perhaps SQLite v3 has a different invocation / driver\nname?\n\nBTW, I just doublechecked, cvsserver isn't mangling the lib path in\nany way. However, the environment it's running under may have a\nstrange PERL5LIB.\n\ncheers,\n\n\nmartin\n"},{"id":"26130","messageId":"20060831090333.GA28445@fiberbit.xs4all.nl","threadId":"5433","inReplyTo":"46a038f90608301329n14df4dd2tb1563cc48662cd14@mail.gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-08-31T09:03:33Z","receivedAt":"2006-08-31T09:03:33Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:\n\n> [git-cvsserver and trouble with Perl DBI and SQLite]\n> \n> Actually, just looking at my etch dev box, libdbd-sqlite-perl is\n> 0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is\n> significant. Perhaps SQLite v3 has a different invocation / driver\n> name?\n\nYes, SQLite v2 and SQLite v3 are different and binary incompatible.\n\nHowever, on Debian 'etch' you can install packages for both versions\nconcurrently; most packages for SQLite have either a '2' or a '3' in the\nname. Packages without the number use the \"best current choice\" which is\n\"3\" in 'etch' at the moment but was \"2\" not too long ago.\n\nSo at this moment in Debian 'etch' SQLite3 is the default version and\ncalling\n\n my $dsn = 'dbi:SQLite:dbname=foo';\n\nwill use the SQLite3 driver internally, for which you must have\ninstalled the \"libdbd-sqlite3-perl\" package. Just for the record, if\nyou'd wanted the older SQLite2 version you would install the\n\"libdbd-sqlite2-perl\" package and from Perl call \"my $dsn =\n'dbi:SQLite2:dbname=foo';\".\n\nI'd guess that you were unfortunate enough to just install some packages\nduring the transition and now some parts look for the \"2\" version\nand other parts for the \"3\" version. Probably just installing the\n\"libdbd-sqlite3-perl\" package and upgrading the other sqlite packages\n(from synaptic say to easily find them!) will probably cure your situation.\n\nIncidentally I'd guess that in itself SQLite2 (so version 2) would also\nfunction perfectly well for git-cvsserver (as would PostgreSQL or\nMySQL), it's probably in this case just a slight version skew between\npackages!\n-- \nMarco Roeland\n"},{"id":"26136","messageId":"44F6D064.9020002@gmail.com","threadId":"5433","inReplyTo":"20060831090333.GA28445@fiberbit.xs4all.nl","subject":"Re: problem with git-cvsserver","fromName":"aonghus","fromEmail":"thecolourblue@gmail.com","sentAt":"2006-08-31T12:04:52Z","receivedAt":"2006-08-31T12:04:52Z","isPatch":false,"sender":{"key":"thecolourblue@gmail.com","avatar":null},"body":"Marco Roeland wrote:\n> On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:\n>\n> \n>> [git-cvsserver and trouble with Perl DBI and SQLite]\n>>\n>> Actually, just looking at my etch dev box, libdbd-sqlite-perl is\n>> 0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is\n>> significant. Perhaps SQLite v3 has a different invocation / driver\n>> name?\n>> \n>\n> Yes, SQLite v2 and SQLite v3 are different and binary incompatible.\n>\n> However, on Debian 'etch' you can install packages for both versions\n> concurrently; most packages for SQLite have either a '2' or a '3' in the\n> name. Packages without the number use the \"best current choice\" which is\n> \"3\" in 'etch' at the moment but was \"2\" not too long ago.\n>\n> So at this moment in Debian 'etch' SQLite3 is the default version and\n> calling\n>\n> my $dsn = 'dbi:SQLite:dbname=foo';\n>\n> will use the SQLite3 driver internally, for which you must have\n> installed the \"libdbd-sqlite3-perl\" package. Just for the record, if\n> you'd wanted the older SQLite2 version you would install the\n> \"libdbd-sqlite2-perl\" package and from Perl call \"my $dsn =\n> 'dbi:SQLite2:dbname=foo';\".\n>\n> I'd guess that you were unfortunate enough to just install some packages\n> during the transition and now some parts look for the \"2\" version\n> and other parts for the \"3\" version. Probably just installing the\n> \"libdbd-sqlite3-perl\" package and upgrading the other sqlite packages\n> (from synaptic say to easily find them!) will probably cure your situation.\n>\n> Incidentally I'd guess that in itself SQLite2 (so version 2) would also\n> function perfectly well for git-cvsserver (as would PostgreSQL or\n> MySQL), it's probably in this case just a slight version skew between\n> packages!\n> \n\nHi,\n\nThanks for all the help- I have it working now. It was not a fault with \ngit-cvsserver at all- more like my own stupidity. The problem was that I \nhad checked the versions on my client machine and forgotten to update \nthe cvs/git server! Once I updated it and installed the \nlibdbd-sqlite3-perl package (on the server) everything works as expected.\n \nSo, just to confirm, git-cvsserver is working on a debian \ntesting/unstable machine (acting cvs/git server) with the following \nversions:\n\n libdbd-sqlite3-perl (1.12-1)\n libdbi-perl (1.51-2)\n libsqlite3-0 (3.3.7-1)\n perl (5.8.8-6.1)\n perl-base (5.8.8-6.1)\n\n\nApologies for wasting your time, looks like my caffeine levels are \ngetting dangerously low...\n\na\n\n \n"},{"id":"26168","messageId":"46a038f90608311600p747c8a3anbe90dbac928e9923@mail.gmail.com","threadId":"5433","inReplyTo":"20060831090333.GA28445@fiberbit.xs4all.nl","subject":"Re: problem with git-cvsserver","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-08-31T23:00:47Z","receivedAt":"2006-08-31T23:00:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/31/06, Marco Roeland wrote:\n> Yes, SQLite v2 and SQLite v3 are different and binary incompatible.\n>\n> However, on Debian 'etch' you can install packages for both versions\n> concurrently; most packages for SQLite have either a '2' or a '3' in the\n> name. Packages without the number use the \"best current choice\" which is\n> \"3\" in 'etch' at the moment but was \"2\" not too long ago.\n\nThanks for the info!\n\nI have to say though: Ouch. Do you know if there's an upgrade path for\napps? Does v3 detect you've got a v2 file and do something smart\n(upgrade in place / spit out a readable error)?\n\n...\n\n> I'd guess that you were unfortunate enough to just install some packages\n> during the transition\n\nProblem is that we have to help with the transition for users that\nstarted with v2 and get upgraded to v3 at the app level I suspect.\n\n> Incidentally I'd guess that in itself SQLite2 (so version 2) would also\n> function perfectly well for git-cvsserver (as would PostgreSQL or\n> MySQL)\n\nThis was developed against v2. If v3 is backwards compatible, it'll\njust work. If not... we'll hear about it soon ;-) Pg/MySQL aren't\nreally supported, though it wouldn't be that hard.\n\n\n\nmartin\n"},{"id":"26171","messageId":"Pine.LNX.4.63.0609010110540.28360@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5433","inReplyTo":"46a038f90608311600p747c8a3anbe90dbac928e9923@mail.gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-31T23:13:27Z","receivedAt":"2006-08-31T23:13:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 1 Sep 2006, Martin Langhoff wrote:\n\n> Pg/MySQL aren't really supported, though it wouldn't be that hard.\n\nAFAIK Pg/MySQL/all-the-others want to have a common place where to put the \ndatabase files. This is a huge disadvantage over SQLite, where you can put \nit anywhere you want (e.g. /blabla/.git/...). This also makes installation \nway easier.\n\nCiao,\nDscho\n"},{"id":"26177","messageId":"46a038f90608311707t4ab5fc2fj45e852df4b91870f@mail.gmail.com","threadId":"5433","inReplyTo":"46a038f90608311600p747c8a3anbe90dbac928e9923@mail.gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-09-01T00:07:19Z","receivedAt":"2006-09-01T00:07:19Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/1/06, Martin Langhoff wrote:\n> I have to say though: Ouch. Do you know if there's an upgrade path for\n> apps? Does v3 detect you've got a v2 file and do something smart\n> (upgrade in place / spit out a readable error)?\n\nOh, grumble. See the comment at the bottom of\nhttp://www.sqlite.org/formatchng.html\n\nWe may need to add something in the doco pointing to this \"technique\",\nand perhaps the URL as later versions may do something different.\n\nI do wonder what the debian packaging does, perhaps the v3 package\nforces an upgrade to the v2 package that renames the cli binary? I\nguess the drawback of having the DBs anywhere in the FS is that the\npackaging can't upgrade them for you as it does with Pg for instance\n:(\n\n\n\nm\n"},{"id":"26179","messageId":"20060901070559.GA22015@fiberbit.xs4all.nl","threadId":"5433","inReplyTo":"46a038f90608311707t4ab5fc2fj45e852df4b91870f@mail.gmail.com","subject":"Re: problem with git-cvsserver","fromName":"Marco Roeland","fromEmail":"marco.roeland@xs4all.nl","sentAt":"2006-09-01T07:05:59Z","receivedAt":"2006-09-01T07:05:59Z","isPatch":false,"sender":{"key":"marco.roeland@xs4all.nl","avatar":null},"body":"On Friday September 1st 2006 at 12:07 Martin Langhoff wrote:\n\n[warning: discussion about sqlite; no direct git serviceable parts inside!]\n\n> >I have to say though: Ouch. Do you know if there's an upgrade path for\n> >apps? Does v3 detect you've got a v2 file and do something smart\n> >(upgrade in place / spit out a readable error)?\n\nApplications for both v2 and v3 can work on the same machine at the same\ntime. Both versions will not corrupt a database of the other version\nand will immediately stop with an error, although the error isn't very\nreadable (doesn't mention _which_ version it saw or needed).\n\nThey do not perform an upgrade in place.\n\nBut as sqlite or sqlite3 databases are standalone files, most of the\ntime just use the sqlite version that is standard for your platform\nand/or version. For new development v3 is the way to go, as v2 is in\ndeep sleep maintenance now.\n\nNot just the database format changed in v3, the whole API changed\nincompatibly.\n\n> Oh, grumble. See the comment at the bottom of\n> http://www.sqlite.org/formatchng.html\n> \n> We may need to add something in the doco pointing to this \"technique\",\n> and perhaps the URL as later versions may do something different.\n> \n> I do wonder what the debian packaging does, perhaps the v3 package\n> forces an upgrade to the v2 package that renames the cli binary? I\n> guess the drawback of having the DBs anywhere in the FS is that the\n> packaging can't upgrade them for you as it does with Pg for instance\n> :(\n\nThe commandline programs are called 'sqlite' and 'sqlite3' so there is\nno \"upgrade\", you can have the two different versions simultaneously\ninstalled and working on the same machine.\n\nUnfortunately the 'sqlite3' doesn't directly read the 'sqlite' format\nand neither the other way round. You can convert a database easily from\nthe one format to the other:\n\n$ echo .dump | sqlite database.v2.dat > dump.v2.dat\n$ sqlite3 < dump.v2.dat database.v3.dat\n\nIf you don't use the new features in sqlite3 you can even convert back\nin the same way:\n\n$ echo .dump | sqlite3 database.v3.dat > dump.v3.dat\n$ sqlite < dump.v3.dat database.v2.dat\n\nUse a non-existent file for the target database, and sqlite(3) will\ncreate the database for you. Do check the conversion as error reporting\nin the commandline tools in this \"batch\" mode is sometimes rather sparse\nor non-existent!\n\nOnce you got it finally going I find that sqlite(3) is a fast, reliable\nand quite handy database. Especially, as Johannes said, its standalone\nnature makes developing and deploying very easy.\n-- \nMarco Roeland\n"}]}