Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sun, Oct 12, 2008, Markus Wanner wrote: > Ralf S. Engelschall wrote: > > Ok, I finally found time to finish the preparation of the SQLite > > upgrade. Sorry for the delay, I was heavily busy because of my day job. > > I've pushed the following two branches to monotone.ca today: > > > > o net.venge.monotone.rse.sqlite-upgrade > > ... > > o net.venge.monotone.rse.sqlite-upgrade-amalgamation > > ... > > I've revisited those branches, but decided to follow the spirit of > nvm.stripped and made mtn link against a system provided sqlite3 library > instead, at least for the nvm.stripped branch for now. > > We can still revert to include the amalgamation later on, I think. > What's most important for me now is making monotone compatible with > newer sqlite versions. > > Do you mind suspending these branches? No, but important for me is that the next versions of Monotone use the newer SQLite versions. Either with an updated included copy or linked externally. Link everything externally (as the .stripped branch seems to try) is also my personal favorite approach... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: > Ok, I finally found time to finish the preparation of the SQLite > upgrade. Sorry for the delay, I was heavily busy because of my day job. > I've pushed the following two branches to monotone.ca today: > > o net.venge.monotone.rse.sqlite-upgrade > ... > o net.venge.monotone.rse.sqlite-upgrade-amalgamation > ... I've revisited those branches, but decided to follow the spirit of nvm.stripped and made mtn link against a system provided sqlite3 library instead, at least for the nvm.stripped branch for now. We can still revert to include the amalgamation later on, I think. What's most important for me now is making monotone compatible with newer sqlite versions. Do you mind suspending these branches? Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Tue, Jun 10, 2008, Zack Weinberg wrote: > (accidental off-list reply, sorry if you get this twice) > > On Tue, Jun 10, 2008 at 12:41 PM, Ralf S. Engelschall > <[EMAIL PROTECTED]> wrote: > > > > Yes, the actual _reason_ why just those two commands fail I don't know > > myself until now. But it seems to be related to the fact SQLite changed > > its OS abstraction layer as this is the major change between SQLite 3.4 > > and 3.5 which can cause a difference here. OTOH for Monotone's SQLite > > operations this isn't really a problem IMHO -- except that we would like > > to understand the failure, of course. > > Agreed. > > Will you have time this week to capture straces of before/after mtn > executing those commands under those conditions? I would do it myself > but I may not have a chance this week 'cos I'm in the middle of moving > across the country. Ok, when I find time the next days I'll try to look at this issue again in more depth. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone upgrade policy for the SQLite copy?
(accidental off-list reply, sorry if you get this twice) On Tue, Jun 10, 2008 at 12:41 PM, Ralf S. Engelschall <[EMAIL PROTECTED]> wrote: > > Yes, the actual _reason_ why just those two commands fail I don't know > myself until now. But it seems to be related to the fact SQLite changed > its OS abstraction layer as this is the major change between SQLite 3.4 > and 3.5 which can cause a difference here. OTOH for Monotone's SQLite > operations this isn't really a problem IMHO -- except that we would like > to understand the failure, of course. Agreed. Will you have time this week to capture straces of before/after mtn executing those commands under those conditions? I would do it myself but I may not have a chance this week 'cos I'm in the middle of moving across the country. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Mon, Jun 09, 2008, Zack Weinberg wrote: > On Sat, Jun 7, 2008 at 2:19 PM, Ralf S. Engelschall > <[EMAIL PROTECTED]> wrote: > [...] > > As mentioned already a few weeks ago, both upgrades pass > > "make check", but I had to disable two little commands in > > tests/fail_cleanly_on_unreadable_db/__driver__.lua because of SQLite > > 3.5's different OS abstraction layer. > > I did look at this change, and I'd like to understand why those > commands fail under those circumstances. I don't immediately see why > those two commands should fail and not the other ones in that block. Yes, the actual _reason_ why just those two commands fail I don't know myself until now. But it seems to be related to the fact SQLite changed its OS abstraction layer as this is the major change between SQLite 3.4 and 3.5 which can cause a difference here. OTOH for Monotone's SQLite operations this isn't really a problem IMHO -- except that we would like to understand the failure, of course. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Jun 7, 2008 at 2:19 PM, Ralf S. Engelschall <[EMAIL PROTECTED]> wrote: > On Sat, Mar 29, 2008, Ralf S. Engelschall wrote: > > Ok, I finally found time to finish the preparation of the SQLite > upgrade. Sorry for the delay, I was heavily busy because of my day job. Thank you. I'm afraid I'm not going to be able to look at this in the next few days. One thing though - > As mentioned already a few weeks ago, both upgrades pass > "make check", but I had to disable two little commands in > tests/fail_cleanly_on_unreadable_db/__driver__.lua because of SQLite > 3.5's different OS abstraction layer. I did look at this change, and I'd like to understand why those commands fail under those circumstances. I don't immediately see why those two commands should fail and not the other ones in that block. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Mar 29, 2008, Ralf S. Engelschall wrote: > While looking at compile-time warnings of Monotone, I've just stumpled > over the fact that we are still using SQLite 3.4.2 in Monotone while at > sqlite.org we already have SQLite 3.5.7 released recently. > [...] Ok, I finally found time to finish the preparation of the SQLite upgrade. Sorry for the delay, I was heavily busy because of my day job. I've pushed the following two branches to monotone.ca today: o net.venge.monotone.rse.sqlite-upgrade This is a straight-forward upgrade of net.venge.monotone from the (pre-processed) standard copy of SQLite SQLite version 3.4.2 to the latest version 3.5.9. The standard copy of SQLite is based on the individual src/*.[ch] files of the SQLite distribution but with the SQLite code pre-processing step already performed (which creates the parser and some tables, etc). o net.venge.monotone.rse.sqlite-upgrade-amalgamation This is an upgrade of net.venge.monotone from the (pre-processed) standard copy of SQLite SQLite version 3.4.2 to the "amalgamation" version of SQLite 3.5.9. The "amalagmation" version is a pre-processed SQLite which is merged into the two files sqlite3.[ch] only. As mentioned already a few weeks ago, both upgrades pass "make check", but I had to disable two little commands in tests/fail_cleanly_on_unreadable_db/__driver__.lua because of SQLite 3.5's different OS abstraction layer. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Mon, Apr 28, 2008, Zack Weinberg wrote: > On Tue, Apr 8, 2008 at 6:58 AM, Ralf S. Engelschall > <[EMAIL PROTECTED]> wrote: > > > Please do [the sqlite 3.5 upgrade] 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. > > > > Ok, I'll commit to a separate branch soon. > > What's the status of this project? Sorry, I was first totally busy and then forgot about this. Will finish these days. Sorry for the delay... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Tue, Apr 8, 2008 at 6:58 AM, Ralf S. Engelschall <[EMAIL PROTECTED]> wrote: > > Please do [the sqlite 3.5 upgrade] 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. > > Ok, I'll commit to a separate branch soon. What's the status of this project? zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Mon, Apr 07, 2008, Zack Weinberg wrote: > On Mon, Apr 7, 2008 at 4:41 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > Looks like I've misread the warning from their migration page. See > > http://www.sqlite.org/34to35.html, that one states: > > > > > SQLite version 3.5.0 introduces a new OS interface layer that is > > > incompatible with all prior versions of SQLite > > > > Obviously they really mean the "interface layer" exclusively, but not the > > on-disk format itself. Thus it's all good and I beg you pardon for the > > noise. > > Yeah, that scared me a bit too, but upon reading more of their docs, > I'm pretty sure that's an *internal* API, only relevant to people who > (for instance) use SQLite on weird embedded platforms and can't use > the normal Unix primitives for access to permanent storage. Exactly, it is the underlying OS API which was revamped in SQLite 3.5. It doesn't hurt the on-disk format and it also usually doesn't affect any SQLite based applications like Monotone -- at least as long as one doesn't fiddle around with the underlying OS-related SQLite API (which is not the case for Monotone). Even in OpenPKG I've not found any application which was broken after the SQLite 3.4 to 3.5 upgrade. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sun, Apr 06, 2008, Markus Schiltknecht wrote: > [...] >> 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. Ok, I'll commit to a separate branch soon. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Mon, Apr 7, 2008 at 4:41 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > Looks like I've misread the warning from their migration page. See > http://www.sqlite.org/34to35.html, that one states: > > > SQLite version 3.5.0 introduces a new OS interface layer that is > > incompatible with all prior versions of SQLite > > Obviously they really mean the "interface layer" exclusively, but not the > on-disk format itself. Thus it's all good and I beg you pardon for the > noise. Yeah, that scared me a bit too, but upon reading more of their docs, I'm pretty sure that's an *internal* API, only relevant to people who (for instance) use SQLite on weird embedded platforms and can't use the normal Unix primitives for access to permanent storage. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Zack Weinberg wrote: As best I can tell from reading the sqlite releases page [ http://sqlite.org/changes.html ] there are no on-disk format changes between the version we have and the latest one. Looks like I've misread the warning from their migration page. See http://www.sqlite.org/34to35.html, that one states: > SQLite version 3.5.0 introduces a new OS interface layer that is > incompatible with all prior versions of SQLite Obviously they really mean the "interface layer" exclusively, but not the on-disk format itself. Thus it's all good and I beg you pardon for the noise. Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sun, Apr 6, 2008 at 9:45 AM, Markus Schiltknecht <[EMAIL PROTECTED]> wrote: > > 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? As best I can tell from reading the sqlite releases page [ http://sqlite.org/changes.html ] there are no on-disk format changes between the version we have and the latest one. zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Apr 05, 2008, Markus Schiltknecht wrote: > Ralf S. Engelschall wrote: >> The alternative is to place a full SQLite build-environment 1:1 into >> sqlite/ and also run its own "configure" step during Monotone's >> "configure" step. > > Yes, that's what I've been talking about and what nvm.library-build is all > about. > >> No, the amalgamation "sqlite3.c" file is not really pre-processed in >> the meaning of the C pre-processor. But it is pre-processed in the >> meaning of the Lemon parsor generator, etc. It is more or less just >> a concatenation of the *.c source files (where parse.c is also used >> instead of parse.y, etc). > > Aha, okay. Do you think we should use that, as recommended by sqlite.org? 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. > >> Ok, I've it running. I dropped sqlite/*, added sqlite3.[ch] and >> adjusted the Monotone build-environment for this. I'm now checking the >> functionality under run-time (especially via the test suite)... > > Cool. Already gotten results from the testsuite? Yes, everything works except 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. > Do you mind publishing your changes? That might get useful in > nvm.library-build. Maybe we can upgrade to sqlite 3.5 first, then propagate > nvm.library-build? 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? Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: The alternative is to place a full SQLite build-environment 1:1 into sqlite/ and also run its own "configure" step during Monotone's "configure" step. Yes, that's what I've been talking about and what nvm.library-build is all about. No, the amalgamation "sqlite3.c" file is not really pre-processed in the meaning of the C pre-processor. But it is pre-processed in the meaning of the Lemon parsor generator, etc. It is more or less just a concatenation of the *.c source files (where parse.c is also used instead of parse.y, etc). Aha, okay. Do you think we should use that, as recommended by sqlite.org? Ok, I've it running. I dropped sqlite/*, added sqlite3.[ch] and adjusted the Monotone build-environment for this. I'm now checking the functionality under run-time (especially via the test suite)... Cool. Already gotten results from the testsuite? Do you mind publishing your changes? That might get useful in nvm.library-build. Maybe we can upgrade to sqlite 3.5 first, then propagate nvm.library-build? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Mar 29, 2008, Markus Schiltknecht wrote: > Ralf S. Engelschall wrote: >> As Monotone is already using its own build-environment > > ..which is a bad thing(tm), which we want to get rid of, IMO... The alternative is to place a full SQLite build-environment 1:1 into sqlite/ and also run its own "configure" step during Monotone's "configure" step. Certainly more complex, but as for SQLite 3.5 I now at least had to extend the m4/sqlite.m4 a little bit, it would prevent that Monotone configure SQLite differently than the SQLite upstream vendor intended. >> for building the >> sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to >> just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. > > As far as I understand, the point of amalgamation is, that there's only one > preprocessed C file. No, the amalgamation "sqlite3.c" file is not really pre-processed in the meaning of the C pre-processor. But it is pre-processed in the meaning of the Lemon parsor generator, etc. It is more or less just a concatenation of the *.c source files (where parse.c is also used instead of parse.y, etc). >> Fully backward compatible on-disk format will be not possible in the >> long-term, so as long as a dump/restore is still possible everything >> should be fine. > > This is an SQL database - they cannot drop dump/restore upgrading > possibility without loosing most users ;-) Sure. Sorry for not being clear enough: I just meant "fully backward compatibility _without_ dump/restore requirements" (= just by upgrading to a newer SQLite version). >> Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x > > Very cool, thanks! And good luck! Ok, I've it running. I dropped sqlite/*, added sqlite3.[ch] and adjusted the Monotone build-environment for this. I'm now checking the functionality under run-time (especially via the test suite)... Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: As Monotone is already using its own build-environment ..which is a bad thing(tm), which we want to get rid of, IMO... for building the sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. As far as I understand, the point of amalgamation is, that there's only one preprocessed C file. Fully backward compatible on-disk format will be not possible in the long-term, so as long as a dump/restore is still possible everything should be fine. This is an SQL database - they cannot drop dump/restore upgrading possibility without loosing most users ;-) Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x Very cool, thanks! And good luck! Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
On Sat, Mar 29, 2008, Markus Schiltknecht wrote: > Ralf S. Engelschall wrote: > [...] > > For the bundled sqlite variant, we should IMO switch to the amalgamation > distribution. As Monotone is already using its own build-environment for building the sqlite/*.c files we instead actually can switch from sqlite/*.[ch] to just the sqlite3.[ch] files from the SQLite "amalgamation" distribution. >> If there is still no such policy I personally recommend a policy like >> this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone >> should can be upgraded to the latest version of SQLite as long as (1) >> this SQLite version it is fully backward compatible to the old on disk >> format (= is able to read it) and at maximum a dump/restore of the >> database is necessary, > > What minimum requirement are you proposing here? Fully backward compatible > (on disk format) *or* dump/restore? Fully backward compatible on-disk format will be not possible in the long-term, so as long as a dump/restore is still possible everything should be fine. At least as long as Monotone is in heavy "development mode" (versions 0.xx) a dump/restore is fully acceptable IMHO. But once Monotone reached something like a version above 1.0, a full dump/restore is IMHO only acceptable any longer for a jump between N.M.x and N.(M+1).0 but not between N.M.x and M.M.(x+k). But we are still not at this point in time... > Especially when we allow linking against system libraries, we have to be > careful and check multiple versions. Maybe even provide a "downgrade" > feature, i.e. if a user first uses a newish system provided sqlite, then > downgrades to the monotone provided one by building mtn from source. > However, dump/restore should do the trick. Yes, for those scenarious a dump/restore will be necessary. > [...] > Yes, there are pretty obvious, IMO. I don't think we are lacking a policy. > We need someone to just *do* it. Are you volunteering to test monotone > against sqlite 3.5.x? Or try integrating the amalgamation distribution? Ok, I volunteer and will try to upgrade and test Monotone with SQLite 3.5.x Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Monotone upgrade policy for the SQLite copy?
Hi, Ralf S. Engelschall wrote: While looking at compile-time warnings of Monotone, I've just stumpled over the fact that we are still using SQLite 3.4.2 in Monotone while at sqlite.org we already have SQLite 3.5.7 released recently. My simple question is: what is the "official" Monotone upgrade policy with respect to the embedded copy of SQLite? I guess simply because noone has taken care, recently. Matthew did the last update to 3.4.2 on 2007-08-14. Please also note, that 3.4.2 is the latest 3.4 release and 3.5.0 features some incompatibilities with older versions, see: http://www.sqlite.org/34to35.html > Who takes care of the SQLite upgrades for Monotone? I've started picking up the nvm.library-build branch, where we strive for accepting system libraries as well. IMO that includes the ability to ling against a system provided sqlite library. For the bundled sqlite variant, we should IMO switch to the amalgamation distribution. If there is still no such policy I personally recommend a policy like this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone should can be upgraded to the latest version of SQLite as long as (1) this SQLite version it is fully backward compatible to the old on disk format (= is able to read it) and at maximum a dump/restore of the database is necessary, What minimum requirement are you proposing here? Fully backward compatible (on disk format) *or* dump/restore? Especially when we allow linking against system libraries, we have to be careful and check multiple versions. Maybe even provide a "downgrade" feature, i.e. if a user first uses a newish system provided sqlite, then downgrades to the monotone provided one by building mtn from source. However, dump/restore should do the trick. (2) it's API is backward compatible or Monotone's use of the SQLite API is at least simultaneous adjusted during the upgrade; (3) Monotone after the upgrade still passes its test suite and (4) in case of a required non-automated upgrade step hints about this are added to file UPGRADING". Yes, there are pretty obvious, IMO. I don't think we are lacking a policy. We need someone to just *do* it. Are you volunteering to test monotone against sqlite 3.5.x? Or try integrating the amalgamation distribution? Regards Markus ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Monotone upgrade policy for the SQLite copy?
While looking at compile-time warnings of Monotone, I've just stumpled over the fact that we are still using SQLite 3.4.2 in Monotone while at sqlite.org we already have SQLite 3.5.7 released recently. My simple question is: what is the "official" Monotone upgrade policy with respect to the embedded copy of SQLite? Who takes care of the SQLite upgrades for Monotone? If there is still no such policy I personally recommend a policy like this (and saved for reference into e.g. "sqlite/README.MTN"): "Monotone should can be upgraded to the latest version of SQLite as long as (1) this SQLite version it is fully backward compatible to the old on disk format (= is able to read it) and at maximum a dump/restore of the database is necessary, (2) it's API is backward compatible or Monotone's use of the SQLite API is at least simultaneous adjusted during the upgrade; (3) Monotone after the upgrade still passes its test suite and (4) in case of a required non-automated upgrade step hints about this are added to file UPGRADING". Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
