Trent Nelson wrote on Wed, Mar 14, 2012 at 15:05:20 -0700:
> On 3/14/12 3:40 PM, "Daniel Shahaf" wrote:
>
> >Philip: I recalled last year's discussions about implied indexes, but
> >between Trent's reported observations on IRC and a back-of-the-envelope
> >test with sqlite3(1) I was led to believ
On 3/14/12 3:40 PM, "Daniel Shahaf" wrote:
>Philip: I recalled last year's discussions about implied indexes, but
>between Trent's reported observations on IRC and a back-of-the-envelope
>test with sqlite3(1) I was led to believe that an implied index does not
>get created for in this case (due t
On Wed, Mar 14, 2012 at 09:53:02PM +0100, Dmitry Pavlenko wrote:
> Hello!
>
> I've found a potential bug in
> svn_wc__db_wcroot_parse_local_abspath
> function.
>
> Suppose the following directories structure:
>
> working_copy_root
> |
>+nested_working_copy_root
>+not_version
Hello!
I've found a potential bug in
svn_wc__db_wcroot_parse_local_abspath
function.
Suppose the following directories structure:
working_copy_root
|
+nested_working_copy_root
+not_versioned_symlink
Suppose also that not_versioned_symlink points to "nested_working_copy_root".
On Wed, Mar 14, 2012 at 16:01, Stefan Sperling wrote:
>...
> This only affects working copies which contain moves recorded by
> a trunk svn client. Once the branch is reintegrated, those moves
> will stop working as expected.
>
> Given that the current target audience of trunk clients is reading
>
On Wed, Mar 14, 2012 at 06:28:40PM +, Philip Martin wrote:
> "C. Michael Pilato" writes:
>
> > On 03/14/2012 01:58 PM, Philip Martin wrote:
> >> $ svn mv wc/A/g wc/g # using trunk
> >> A wc/g
> >> D wc/A/f
> >> $ svn st wc # using trunk
> >> D wc/A/f
> >>
Philip: I recalled last year's discussions about implied indexes, but
between Trent's reported observations on IRC and a back-of-the-envelope
test with sqlite3(1) I was led to believe that an implied index does not
get created for in this case (due to the TEXT column, as my comment
says).
I'm more
On Wed, Mar 14, 2012 at 12:48 PM, Branko Čibej wrote:
> On 14.03.2012 17:08, Hyrum K Wright wrote:
>> On Wed, Mar 14, 2012 at 10:47 AM, Greg Stein wrote:
>>> Away from laptop right now, but the trace can be printed using
>>> logger.exception(). Not sure where to insert it, but that is the key met
"C. Michael Pilato" writes:
> On 03/14/2012 01:58 PM, Philip Martin wrote:
>> $ svn mv wc/A/g wc/g # using trunk
>> A wc/g
>> D wc/A/f
>> $ svn st wc # using trunk
>> D wc/A/f
>> > moved to wc/g
>> A +wc/g
>> > moved from wc/A/f
>>
>> If we n
On 03/14/2012 01:58 PM, Philip Martin wrote:
> $ svn mv wc/A/g wc/g # using trunk
> A wc/g
> D wc/A/f
> $ svn st wc # using trunk
> D wc/A/f
> > moved to wc/g
> A +wc/g
> > moved from wc/A/f
>
> If we now use the branch on that working copy:
>
phi...@apache.org writes:
> Author: philip
> Date: Wed Mar 14 17:13:42 2012
> New Revision: 1300647
>
> URL: http://svn.apache.org/viewvc?rev=1300647&view=rev
> Log:
> On multi-layer-move branch, remove an excessively strict check and allow
> a node to be both moved_to and moved_here. copy_tests
On 14.03.2012 17:08, Hyrum K Wright wrote:
> On Wed, Mar 14, 2012 at 10:47 AM, Greg Stein wrote:
>> Away from laptop right now, but the trace can be printed using
>> logger.exception(). Not sure where to insert it, but that is the key method.
> logger.execption() always logs at the ERROR level, an
On Wed, Mar 14, 2012 at 11:44 AM, Greg Stein wrote:
> I don't see how this affects the logging at all. Before/after, you're
> still calling _log_exception(), but now without a specified message.
That isn't completely true. _log_exception() only gets called once
per exception.
The original code
I don't see how this affects the logging at all. Before/after, you're
still calling _log_exception(), but now without a specified message.
In fact, won't this (now) generate an empty log message, followed by
the traceback?
Maybe you need to do something like:
msg = traceback.format_exc()
if f
On Wed, Mar 14, 2012 at 10:12 AM, Philip Martin
wrote:
> Philip Martin writes:
>
>> Philip Martin writes:
>>
>>> Philip Martin writes:
>>>
Hyrum K Wright writes:
> Agreed that the stack trace is important here. Do you know in which
> revision it disappeared?
When I
On Wed, Mar 14, 2012 at 10:47 AM, Greg Stein wrote:
> Away from laptop right now, but the trace can be printed using
> logger.exception(). Not sure where to insert it, but that is the key method.
logger.execption() always logs at the ERROR level, and we (I?) are
aiming to keep test failure output
Away from laptop right now, but the trace can be printed using
logger.exception(). Not sure where to insert it, but that is the key method.
On Mar 14, 2012 11:12 AM, "Philip Martin" wrote:
> Philip Martin writes:
>
> > Philip Martin writes:
> >
> >> Philip Martin writes:
> >>
> >>> Hyrum K Wri
Philip Martin writes:
> Philip Martin writes:
>
>> Philip Martin writes:
>>
>>> Hyrum K Wright writes:
>>>
Agreed that the stack trace is important here. Do you know in which
revision it disappeared?
>>>
>>> When I sync'd the branch with the trunk :-P
>>>
>>> I'll have a look.
>>
>>
Philip Martin writes:
> Philip Martin writes:
>
>> Hyrum K Wright writes:
>>
>>> Agreed that the stack trace is important here. Do you know in which
>>> revision it disappeared?
>>
>> When I sync'd the branch with the trunk :-P
>>
>> I'll have a look.
>
> r1297676 produces a Python stack trace
Philip Martin writes:
> Hyrum K Wright writes:
>
>> Agreed that the stack trace is important here. Do you know in which
>> revision it disappeared?
>
> When I sync'd the branch with the trunk :-P
>
> I'll have a look.
r1297676 produces a Python stack trace, r1297712 does not.
--
uberSVN: Apa
Hyrum K Wright writes:
> Agreed that the stack trace is important here. Do you know in which
> revision it disappeared?
When I sync'd the branch with the trunk :-P
I'll have a look.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
On Wed, Mar 14, 2012 at 9:29 AM, Philip Martin
wrote:
> Philip Martin writes:
>
>> With the old testsuite code a test failure resulted in a Python stack
>> trace showing exactly where the error occurred. The new logging doesn't
>> appear to show it. So a failing test looks like:
>>
>> 2012-03-1
Philip Martin writes:
> With the old testsuite code a test failure resulted in a Python stack
> trace showing exactly where the error occurred. The new logging doesn't
> appear to show it. So a failing test looks like:
>
> 2012-03-14 14:11:05 [INFO] CMD: svn unlock
> svn-test-work/working_copi
With the old testsuite code a test failure resulted in a Python stack
trace showing exactly where the error occurred. The new logging doesn't
appear to show it. So a failing test looks like:
2012-03-14 14:11:05 [INFO] CMD: svn unlock
svn-test-work/working_copies/lock_tests-8._b/iota --config-di
24 matches
Mail list logo
