On Sat, Apr 21, 2012 at 5:08 PM, Greg Stein <gst...@gmail.com> wrote: > On Sat, Apr 21, 2012 at 17:59, Daniel Shahaf <danie...@elego.de> wrote: >> Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:00:02 -0500: >>> On Sat, Apr 21, 2012 at 11:51 AM, Stefan Sperling <s...@elego.de> wrote: >>> > On Sat, Apr 21, 2012 at 07:49:37AM -0500, Hyrum K Wright wrote: >>> >> On Fri, Apr 20, 2012 at 10:15 PM, Greg Stein <gst...@gmail.com> wrote: >>> >> > Seems we can/should have a runtime version check? Avoid running with >>> >> > 3.7.11? >>> >> >>> >> I dunno. Arguably, there are bugs in many versions of our dependency >>> >> libraries which affect us, yet we don't special case them out. By the >>> >> time anybody upgrades their Subversion to obtain the version check, >>> >> they'll probably have upgraded their SQLite as well, so I don't see it >>> >> as a very big issue. > > Yeah, but 3.7.11 is the "current" version, and we don't know when the > next version will be released. But if we know 1.7.5 is going out > "now", then we can add a check. And who knows about package skew for > the next year or so...
http://www.sqlite.org/draft/releaselog/3_7_12.html says May 4, so roughly two weeks. Though much like our own releases, they are done when they are done. > Maybe I don't understand the bug entirely, but it seems "don't use > this at all" is where we're at. That is very different from some bug > in apr 1.3.2. If this sqlite issue makes svn a total non-starter, then > I think we ought to warn about it. > > And best way is with a runtime check. We could also have a compile > time check, which helps packagers. > > Blair? How badly did this really impact svn? It sounds like it was > only for an upgraded working copy? Upgraded from 1.6? I wonder how an > upgraded wc would differ from a normal checkout... ?? > >>> > I think we should block or at least warn about dependencies with known >>> > bugs. There should be a way to force use of the dependency if necessary >>> > (like the --disable-neon-version-check option). > > Maybe. I think it really depends upon the problem. For example, we > couldn't even *start* svn with 3.7.7. We had to wait for 3.7.7.1 to be > released. No about of "check disable" would allow us to run against > 3.7.7. > >>> It's a slippery slope. We've got a number of dependencies, and there >>> is no possible way to test or even keep up with the various >>> permutations of them that may be installed. We do our best, but I >> >> What permutations? We don't care what the bdb or neon version is when > > Right. > >> checking the sqlite version, and we don't care if there is more than one >> sqlite on the system either. >> >>> just don't think we ought to litter our code with version checks and >>> warnings when we get user-reported issues like this. It's a >>> maintenance nightmare. >> >> How so? Did we have more than one or two of those bugs per year? > > Furthermore, these checks slowly disappear over time. We used to have > a lot of version-dependent code in sqlite.c. But then we said "minimum > version is $whatever" and deleted a bunch of those checks. > > If we put in a check to avoid 3.7.11, then it will get deleted once we > set a 3.8 minimum (for example). > > These checks are also pretty darned isolated. They aren't really > "littered" around the codebase. > >>... >> If we could have the same check either in code or in a documentation >> somewhere, I'd vote for the former. > > I strongly concur. > > Cheers, > -g -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
