Branko Čibej wrote on Fri, Dec 21, 2012 at 23:05:14 +0100:
> On 21.12.2012 20:41, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
> >> On 21.12.2012 19:17, Philip Martin wrote:
> >>> Branko Čibej writes:
> >>>
> On 21.12.2012 18:30, Philip Martin wrote:
> >
On 21.12.2012 20:41, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
>> On 21.12.2012 19:17, Philip Martin wrote:
>>> Branko Čibej writes:
>>>
On 21.12.2012 18:30, Philip Martin wrote:
> Branko Čibej writes:
>
>> Does "make EXTRA_CFLAGS=..." not
julianf...@apache.org wrote on Mon, Dec 03, 2012 at 16:19:45 -:
> Author: julianfoad
> Date: Mon Dec 3 16:19:44 2012
> New Revision: 1416578
>
> URL: http://svn.apache.org/viewvc?rev=1416578&view=rev
> Log:
> A bit of table-driven goodness for the interactive conflict resolver.
>
Nice!
> +
On Fri, Dec 21, 2012 at 1:10 PM, Paul Burba wrote:
> On Fri, Dec 21, 2012 at 11:34 AM, Bert Huijben wrote:
>> The problem is that I didn’t break real changes, but only changed the
>> reporting of entry-prop changes (think: last_*) as real changes.
>>
>> That leaves a probable real bug somewhere e
I just noticed that we insert a node kind into a 'base-deleted' row, at least
in some cases.
wc_db.c: svn_wc__db_extend_parent_delete(... kind ...): stmt =
STMT_INSTALL_WORKING_NODE_FOR_DELETE
svn_sqlite__bindf(... kind ...)
Is there a good reason for this? It makes me feel that it is redu
Branko Čibej wrote on Fri, Dec 21, 2012 at 19:40:03 +0100:
> On 21.12.2012 19:17, Philip Martin wrote:
> > Branko Čibej writes:
> >
> >> On 21.12.2012 18:30, Philip Martin wrote:
> >>> Branko Čibej writes:
> >>>
> Does "make EXTRA_CFLAGS=..." not give you exactly that?
> >>> I want to set th
The current set of changes on the branch was tested on Mac OS, Linux and
FreeBSD, and appears to work as advertised. See detailed description in
http://svn.apache.org/repos/asf/subversion/branches/tweak-build-take-two/BRANCH-README
I think the branch is ready to be merged to trunk. If no-one obje
On 21.12.2012 19:17, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 21.12.2012 18:30, Philip Martin wrote:
>>> Branko Čibej writes:
>>>
Does "make EXTRA_CFLAGS=..." not give you exactly that?
>>> I want to set the flags at configure.
>> Sure, I understand that. But in order to do that,
Branko Čibej writes:
> On 21.12.2012 18:30, Philip Martin wrote:
>> Branko Čibej writes:
>>
>>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
>> I want to set the flags at configure.
>
> Sure, I understand that. But in order to do that, we'd have to introduce
> another variable besides
On Fri, Dec 21, 2012 at 11:34 AM, Bert Huijben wrote:
> The problem is that I didn’t break real changes, but only changed the
> reporting of entry-prop changes (think: last_*) as real changes.
>
> That leaves a probable real bug somewhere else where we skip the processing
> of the real changes (so
On 21.12.2012 18:30, Philip Martin wrote:
> Branko Čibej writes:
>
>> Does "make EXTRA_CFLAGS=..." not give you exactly that?
> I want to set the flags at configure.
Sure, I understand that. But in order to do that, we'd have to introduce
another variable besides C(XX)FLAGS, because those overrid
On 12/21/2012 12:27 PM, cmpil...@apache.org wrote:
> Author: cmpilato
> Date: Fri Dec 21 17:27:03 2012
> New Revision: 1425042
>
> URL: http://svn.apache.org/viewvc?rev=1425042&view=rev
> Log:
> Reintegrate the 'issue-4116-dev' branch into trunk, fixing (as far as
> I can tell) issue #4116 ("svnrd
Branko Čibej writes:
> Does "make EXTRA_CFLAGS=..." not give you exactly that?
I want to set the flags at configure.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
On 21.12.2012 18:07, Philip Martin wrote:
> Philip Martin writes:
>
>> Branko Čibej writes:
>>
>>> On 21.12.2012 16:36, Philip Martin wrote:
So the build system used to strip -std=c89 and now does not. If I
remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>> Thanks. A
On 21.12.2012 18:12, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 21.12.2012 18:03, Branko Čibej wrote:
>>> On 21.12.2012 18:02, Philip Martin wrote:
Branko Čibej writes:
> On 21.12.2012 16:36, Philip Martin wrote:
>> So the build system used to strip -std=c89 and now doe
Branko Čibej writes:
> On 21.12.2012 18:03, Branko Čibej wrote:
>> On 21.12.2012 18:02, Philip Martin wrote:
>>> Branko Čibej writes:
>>>
On 21.12.2012 16:36, Philip Martin wrote:
> So the build system used to strip -std=c89 and now does not. If I
> remove -std=c89 from SWIG_RB_COMP
Philip Martin writes:
> Branko Čibej writes:
>
>> On 21.12.2012 16:36, Philip Martin wrote:
>>> So the build system used to strip -std=c89 and now does not. If I
>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>>
>> Thanks. Apparently I either missed that somehow, or this
On 21.12.2012 18:03, Branko Čibej wrote:
> On 21.12.2012 18:02, Philip Martin wrote:
>> Branko Čibej writes:
>>
>>> On 21.12.2012 16:36, Philip Martin wrote:
So the build system used to strip -std=c89 and now does not. If I
remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works
On 21.12.2012 18:02, Philip Martin wrote:
> Branko Čibej writes:
>
>> On 21.12.2012 16:36, Philip Martin wrote:
>>> So the build system used to strip -std=c89 and now does not. If I
>>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>> Thanks. Apparently I either missed that so
Branko Čibej writes:
> On 21.12.2012 16:36, Philip Martin wrote:
>> So the build system used to strip -std=c89 and now does not. If I
>> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
>
> Thanks. Apparently I either missed that somehow, or this option came
> from the Ruby comp
On 21.12.2012 16:36, Philip Martin wrote:
> So the build system used to strip -std=c89 and now does not. If I
> remove -std=c89 from SWIG_RB_COMPILE in Makefile the build works.
Thanks. Apparently I either missed that somehow, or this option came
from the Ruby compile flags, not ours. Will try to
The problem is that I didn’t break real changes, but only changed the
reporting of entry-prop changes (think: last_*) as real changes.
That leaves a probable real bug somewhere else where we skip the processing
of the real changes (somewhere below the entry prop changes) without even
looking at th
(Dropping 'commits@'.)
Paul Burba wrote:
> On Thu, Dec 20, 2012 at 9:01 AM, wrote:
>> URL: http://svn.apache.org/viewvc?rev=1424469&view=rev
>> Log:
>> In the repository-repository diff handler: Don't retrieve pristine
>> properties when we already know that there are no differences to
>> repo
Branko Čibej writes:
> Can you post the actual compiler-via-libtool invocation, so that I can
> see which options came through to confuse the compiler?
This is the working line (with a number of compiler flags from my normal
build):
/bin/sh /home/pm/sw/subversion/obj/libtool --tag=CC --silent -
On Thu, Dec 20, 2012 at 9:01 AM, wrote:
> Author: rhuijben
> Date: Thu Dec 20 14:01:37 2012
> New Revision: 1424469
>
> URL: http://svn.apache.org/viewvc?rev=1424469&view=rev
> Log:
> In the repository-repository diff handler: Don't retrieve pristine properties
> when we already know that there a
On 21.12.2012 16:03, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Dec 21, 2012 at 15:03:15 +0100:
>> You probably noticed that I made a bunch of build system modifications
>> on a branch. The individual changes are described in the BRANCH-README
>> file (see below), with "svn diff" invocations
On 21.12.2012 15:55, Philip Martin wrote:
> Branko Čibej writes:
>
>> Please take time to review these changes and test them. I did my best to
>> test on Mac OS and Linux, but as we saw in the previous iteration,
>> autoconf isn't exactly obvious. As usual, I can't build swig-db and
>> swig-py, bu
Branko Čibej wrote on Fri, Dec 21, 2012 at 15:03:15 +0100:
> You probably noticed that I made a bunch of build system modifications
> on a branch. The individual changes are described in the BRANCH-README
> file (see below), with "svn diff" invocations that make it easier to
> review each change.
>
Branko Čibej writes:
> Please take time to review these changes and test them. I did my best to
> test on Mac OS and Linux, but as we saw in the previous iteration,
> autoconf isn't exactly obvious. As usual, I can't build swig-db and
> swig-py, but did touch their configury.
A plain 'make' work
You probably noticed that I made a bunch of build system modifications
on a branch. The individual changes are described in the BRANCH-README
file (see below), with "svn diff" invocations that make it easier to
review each change.
Please take time to review these changes and test them. I did my be
30 matches
Mail list logo
