On Sat, Apr 21, 2012 at 5:08 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Sat, Apr 21, 2012 at 17:59, Daniel Shahaf <danielsh_at_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 <stsp_at_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 <gstein_at_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/
Received on 2012-04-22 01:21:21 CEST