This discussion is completely idiotic.
On the one hand, we're scared about bumping the version of a tool that
is only used by developers (not tarball consumers) and the test suite
to a version released in November 2004, and which is run as an
executable so you can incredibly easily point the build at a locally
built copy of the tool.
At the same time, we're getting close to shipping Subversion in a
state where building *libsvn_subr* requires you to have a version of
sqlite released in June 2007. And because this is "a linked in
library", building your own copy isn't as simple as setting one
environment variable or editing a shebang line... in fact, despite
asking for help months ago, I still have not figured out how to
successfully build trunk on my work computer (a Ubuntu box with an old
version of sqlite installed globally).
(It's a good thing nobody is paying me to work full time on Subversion
On Tue, Jan 13, 2009 at 3:30 PM, Blair Zajac <blair_at_orcaware.com> wrote:
> Paul Burba wrote:
>> On Mon, Jan 12, 2009 at 4:41 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>>> Paul Burba wrote:
>>>> On Fri, Jan 9, 2009 at 10:23 PM, David Glasser
>>>>> I'm pretty sure we decided to do this several times already. Search for
>>>>> from me about it...
>>>> Dave found this other thread he mentioned above:
>>>> Blair, in that thread you objected to 2.4 at the time because:
>>>>> I suggest bumping to 2.2 since RHEL 4, which is still in a lot
>>>>> of places, is on 2.3. To have to build Python 2.4 or greater
>>>>> just to test svn on RHEL 4 would be a pain.
>>>>> So bump to Python 2.2 but include subprocess.py with the svn test
>>>> Blair, does your previous objection still hold today?
>>> How much work is it to support 2.3 in the current code? I just saw one
>>> commit you had r35193.
>> Hi Blair,
>> Probably not that much, after r35193 I can successfully run the tests
>> with 2.3.5, though I still can't do a fresh rebuild of Subversion with
>> 2.3.5 (I still think that is probably a minor problem, though I
>> haven't tried to fix that since I have only been interested thus far
>> in getting the buildbots working and supporting running the tests in
>> parallel on my own Windows box).
> I updated to r35212 and setting PATH=/usr/bin:/bin and
> PYTHON=/usr/bin/python on our Centos 4 box everything worked fine.
>> So it mostly comes down to the fact that we are trying to maintain the
>> two different code paths for 2.4+ and < 2.4 and does the effort of
>> doing so justify the benefit of supporting < 2.4...
> I think we need to maintain compatibility with tools that build Subversion
> on recent OSes. The fix in r35193, if not applied, would require the
> Subversion packager to build Python and then Subversion. I think overall
> it's probably less effort for us to do this work in one place then require
> anyone on an older OS to build Python.
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
Received on 2009-01-14 00:29:12 CET