|
From: | Markus Schiltknecht |
Subject: | Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy? |
Date: | Sun, 06 Apr 2008 15:45:34 +0200 |
User-agent: | Mozilla-Thunderbird 2.0.0.9 (X11/20080110) |
Hi, Ralf S. Engelschall wrote:
Hmmm... well, I think it would not matter very much whether we use the amalgamation or the regular SQLite. The amalgamation perhaps has the advantage that it is less "intrusive" to the Monotone source tree and that a theoretic compiler code optimization advantage exists.
Well, there must be a reason *they* advice you to use it. And as I haven't heard any convincing counter arguments, I'd go for that, yes.
Yes, everything works except
That's surprising me somewhat. So even the schema_migration test works? Have you ever tried using database files and monotone versions crossed? Can sqlite convert to the new format automatically and internally? What does an old (3.4) sqlite do when fed with a newish (3.5) database file?
for one(!) particular strange test which tests whether SQLite can write to a non-writeable directory, etc. I've already looked at it and I think it doing some assumptions which are no longer true with SQLite 3.5's new OS abstraction layer and so has to be removed IMHO. But I've to look at this again and really find the real reason in order to not do the wrong thing here.
Cool, thanks.
I've still not looked at nvm.library-build in detail but from the commits it looks you are reorganizing the libs there. Looks fine, too. I'll try to upgrade to SQLite 3.5 ASAP and then you can propagate nvm.library-build, too. Ok?
Please do your work in a separate branch, started from nvm. Then we can still decide later on, which one to land first or from which one to propagate to the other one.
Regards Markus
[Prev in Thread] | Current Thread | [Next in Thread] |