Option one would be to offer this from svn cleanup: https://forums.meteor.com/t/how-to-fix-sqlite-corrupt-so-meteor-cli-is-broken/6863/6
cd ~/.meteor/package-metadata/v2.0.1 sqlite3 packages.data.db .dump > backup mv packages.data.db packages.data.db.bustedX sqlite3 packages.data.db < backup rm backup I am not sure what the API equivalent of this is. Obviously this can fail if the dump fails, but that is better than nothing at all. Option two would be to add an option “—repair" to “svn checkout —force” to ignore the existing database but keep the .svn directory including the pristine files. > On 12 Aug 2019, at 19:00, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > > Jens Restemeier wrote on Mon, 12 Aug 2019 14:14 +00:00: >> That is a good point, though I was hoping that implementation details >> like the database library can be handled internally, > > What would you have us do when an SQLite API call returns SQLITE_CORRUPT > (that's the error code you got)? > >> and admin tasks wrapped within the svn frontend.
