On Wed, Jun 13, 2012 at 2:14 AM, Johan Corveleyn wrote:
> So maybe we can take another look at this tomorrow (unless someone
> else fixes it first of course :-)).
It happens here on my Mac too - should be fixed in r1349651. Thanks! -- justin
I created Issue #4193. Thanks.
- Mark
On Tue, Jun 12, 2012 at 3:50 PM, Stefan Sperling wrote:
> On Tue, Jun 12, 2012 at 09:50:17AM -0500, Mark Moe wrote:
>> Hi, Subversion 1.7.x appears to no longer support commit (or add) of a
>> file referenced through a symbolic link. Was this change intend
On Tue, Jun 12, 2012 at 11:20 PM, wrote:
> Author: jerenkrantz
> Date: Tue Jun 12 21:20:51 2012
> New Revision: 1349545
>
> URL: http://svn.apache.org/viewvc?rev=1349545&view=rev
> Log:
> Fix lock tests #37 & #42 by properly calling our XML error response delegator.
>
> * subversion/libsvn_ra_ser
On Tue, Jun 12, 2012 at 11:57 PM, Stefan Sperling wrote:
> On Tue, Jun 12, 2012 at 01:47:13PM +0200, Hyrum K Wright wrote:
>> We've had the "should we remove neon?" discussion before, and the
>> consensus has felt to resolve in the affirmative. Now is the time for
>> action.
>
> We should move th
On Tue, Jun 12, 2012 at 01:47:13PM +0200, Hyrum K Wright wrote:
> We've had the "should we remove neon?" discussion before, and the
> consensus has felt to resolve in the affirmative. Now is the time for
> action.
We should move this issue into the 1.8.0 milestone if neon is deleted:
http://subve
On Tue, Jun 12, 2012 at 09:50:17AM -0500, Mark Moe wrote:
> Hi, Subversion 1.7.x appears to no longer support commit (or add) of a
> file referenced through a symbolic link. Was this change intended or
> should it still work like it did with v1.6.x?
>
> Examples for 1.7.x failing and 1.6.x workin
On 06/12/2012 06:15 AM, hwri...@apache.org wrote:
Author: hwright
Date: Tue Jun 12 13:15:07 2012
New Revision: 1349314
URL: http://svn.apache.org/viewvc?rev=1349314&view=rev
Log:
Add a hack which prevents a trivial compiler warning for me when building with
clang.
* configure.ac:
Filter out
Lock test #37 and #42 is currently failing on Windows (with and
without the virus scanner). See:
http://ci.apache.org/builders/svn-slik-w2k3-x64-ra/builds/4511/steps/Test%20fsfs+serf/logs/faillog
It is related to the special 405/409/500 handler in handle_response
which is "completely wrong". *g
Hi, Subversion 1.7.x appears to no longer support commit (or add) of a
file referenced through a symbolic link. Was this change intended or
should it still work like it did with v1.6.x?
Examples for 1.7.x failing and 1.6.x working shown below.
Thanks,
- Mark
### 1.7.5 ci though link fails ###
cmpil...@apache.org wrote on Tue, Jun 12, 2012 at 14:21:44 -:
> Author: cmpilato
> Date: Tue Jun 12 14:21:44 2012
> New Revision: 1349371
>
> URL: http://svn.apache.org/viewvc?rev=1349371&view=rev
> Log:
> * subversion/libsvn_ra_serf/update.c
> (start_report): Remove commented-out cruft intr
On 06/12/2012 03:20 PM, Daniel Klíma wrote:
> I think, it needs to be postponed as at least one server is failing
> with serf: http://svn.ali.as/cpan Unfortunately it took bit long to
> verify error using TortoiseSVN custom built with 1.8-trunk due to time
> constraints and to verify it with svn it
(Just finishing an unfinished sentence...)
I (Julian Foad) wrote:
> I (Julian Foad) wrote:
>> This is great. You're right, the main thing seems to be that
>> find_symmetric_merge is currently only fetching and analyzing
>> the branch-root mergeinfo. It needs to fetch and analyze all
>> mer
I (Julian Foad) wrote:
> This is great. You're right, the main thing seems to be that
> find_symmetric_merge is currently only fetching and analyzing
> the branch-root mergeinfo. It needs to fetch and analyze all
> mergeinfo on the branch, finding a merge base for each subtree,
> and proceed som
On Tue, Jun 12, 2012 at 3:22 PM, wrote:
> Author: stefan2
> Date: Tue Jun 12 13:22:40 2012
> New Revision: 1349316
>
> URL: http://svn.apache.org/viewvc?rev=1349316&view=rev
> Log:
> Fix "unreachable code" warning under Windows. In the for (i=0;i loop header, the ++i would never be executed. So,
On 06/12/2012 03:20 PM, Daniel Klíma wrote:
> I think, it needs to be postponed as at least one server is failing
> with serf: http://svn.ali.as/cpan Unfortunately it took bit long to
> verify error using TortoiseSVN custom built with 1.8-trunk due to time
> constraints and to verify it with svn it
2012/6/12 Hyrum K Wright :
> We've had the "should we remove neon?" discussion before, and the
> consensus has felt to resolve in the affirmative. Now is the time for
> action.
>
> I've got a 586 kb patch which removes libsvn_ra_neon from trunk. It
> doesn't not remove the --http-library runtime
On Tue, Jun 12, 2012 at 2:38 PM, Lieven Govaerts wrote:
> Attached patch shows what I suggest. The case you probably encounter
> is when the response is handled by handle_server_error.
> This is untested, I don't have a Windows setup ready and didn't
> install my build tools yet after upgrade to O
On Thu, May 31, 2012 at 4:32 PM, Hyrum K Wright
wrote:
> On Thu, May 10, 2012 at 2:13 PM, wrote:
>> Author: rhuijben
>> Date: Thu May 10 19:13:11 2012
>> New Revision: 1336833
>>
>> URL: http://svn.apache.org/viewvc?rev=1336833&view=rev
>> Log:
>> Make the text and property merge handling of 'sv
On Tue, Jun 12, 2012 at 2:18 PM, Lieven Govaerts wrote:
> On Tue, Jun 12, 2012 at 2:00 PM, Justin Erenkrantz
> wrote:
>> On Tue, Jun 12, 2012 at 1:56 PM, Lieven Govaerts wrote:
How is it supposed to retry? ra_serf needs to let the context_run
loop execute again to pull off the remaini
Branko Čibej writes:
> Better than spamming #svn-dev, here's the current list of 64-32bit
> narrowing warnings I get on my 64-bit mac wit Xcode 4.3.3's gcc. Taking
> a quick look at these, every case appears to be a valid warning that
> needs to be looked at and verified that the narrowing doesn'
Better than spamming #svn-dev, here's the current list of 64-32bit
narrowing warnings I get on my 64-bit mac wit Xcode 4.3.3's gcc. Taking
a quick look at these, every case appears to be a valid warning that
needs to be looked at and verified that the narrowing doesn't affect the
value.
i don't kn
On Tue, Jun 12, 2012 at 2:00 PM, Justin Erenkrantz
wrote:
> On Tue, Jun 12, 2012 at 1:56 PM, Lieven Govaerts wrote:
>>> How is it supposed to retry? ra_serf needs to let the context_run
>>> loop execute again to pull off the remaining bits from the socket.
>>> Without the patch, we treat EAGAIN
Markus Schaber writes:
> Here's the third iteration.
I tweaked the log message, split a long line and committed this in
r1349288. Thanks!
I wonder if we could reduce the file IO by comparing all three files in
one operation instead of two operations on pairs of files?
--
uberSVN: Apache Subv
On Tue, Jun 12, 2012 at 1:56 PM, Lieven Govaerts wrote:
>> How is it supposed to retry? ra_serf needs to let the context_run
>> loop execute again to pull off the remaining bits from the socket.
>> Without the patch, we treat EAGAIN as a fatal error and it gets
>> returned all the way to the clie
On Tue, Jun 12, 2012 at 1:50 PM, Johan Corveleyn wrote:
> Justin, here's the patch for the 404 which you made on my machine ...
I'm working on cleaning up this patch...but, with this patch plus the
patch at the beginning of the thread, all of the basic tests now pass
on Johan's machine with the f
On Tue, Jun 12, 2012 at 1:18 PM, Justin Erenkrantz
wrote:
> On Tue, Jun 12, 2012 at 1:01 PM, Lieven Govaerts wrote:
>> That seems strange, serf_context_run is not documented to return
>> APR_EGAIN. While the response handler can return APR_EAGAIN, serf
>> itself will translate this to APR_SUCCESS
On Tue, Jun 12, 2012 at 1:18 PM, Justin Erenkrantz
wrote:
> On Tue, Jun 12, 2012 at 1:01 PM, Lieven Govaerts wrote:
>> That seems strange, serf_context_run is not documented to return
>> APR_EGAIN. While the response handler can return APR_EAGAIN, serf
>> itself will translate this to APR_SUCCESS
We've had the "should we remove neon?" discussion before, and the
consensus has felt to resolve in the affirmative. Now is the time for
action.
I've got a 586 kb patch which removes libsvn_ra_neon from trunk. It
doesn't not remove the --http-library runtime option or config file
code, but does r
Hi, all,
Here's the third iteration.
Compared to the second iteration, I changed the comments a little bit, and now
return svn_wc_merge_unchanged in merge_file_trivial(). This makes all tests in
test_merges.py and test_updates.py pass as expected.
Note that merge_file() in update_editor.c will
Hi Stefan,
Thanks much for your thorough review and detailed suggestions. I have
attached the updated version of patch with your suggested fix. Kindly
verify the same. Looking forward for your inputs.
--
Regards,
Jeyanthan
P.S. Realized it's better to rely on standard editors than sophistica
Justin Erenkrantz writes:
> How is it supposed to retry? ra_serf needs to let the context_run
> loop execute again to pull off the remaining bits from the socket.
> Without the patch, we treat EAGAIN as a fatal error and it gets
> returned all the way to the client. -- justin
There are 2 other
On Tue, Jun 12, 2012 at 1:01 PM, Lieven Govaerts wrote:
> That seems strange, serf_context_run is not documented to return
> APR_EGAIN. While the response handler can return APR_EAGAIN, serf
> itself will translate this to APR_SUCCESS. As a result, ra_serf
> doesn't expect it and - rightfully IMO
On Tue, Jun 12, 2012 at 10:51 AM, Justin Erenkrantz
wrote:
> It seems we've tweaked how we handle EAGAIN inside of ra_serf and are
> treating it as a critical error.
>
> Right now, what Johan is seeing with his anti-virus software is that
> we very often receive EAGAIN from the sockets. However,
On 12.06.2012 10:51, Justin Erenkrantz wrote:
> It seems we've tweaked how we handle EAGAIN inside of ra_serf and are
> treating it as a critical error.
>
> Right now, what Johan is seeing with his anti-virus software is that
> we very often receive EAGAIN from the sockets. However, we're
> treati
On 06/12/2012 12:30 AM, Dmitry Pavlenko wrote:
> [[[
> Add a regression test for r1348822.
>
> * subversion/tests/cmdline/stat_tests.py
> (status_depth_update_local_modifications): Add a test for "svn status -u"
> call
> with different --depth values on a working copy with local modificatio
On 06/12/2012 04:34 AM, C. Michael Pilato wrote:
> On 06/10/2012 12:16 AM, Bert Huijben wrote:
>>> @@ -1214,7 +1215,11 @@ start_xml(void *userData, const char *ra
>>>
>>>svn_ra_serf__expand_ns(&name, parser->state->ns_list, raw_name);
>>>
>>> - parser->error = parser->start(parser, name, attrs
It seems we've tweaked how we handle EAGAIN inside of ra_serf and are
treating it as a critical error.
Right now, what Johan is seeing with his anti-virus software is that
we very often receive EAGAIN from the sockets. However, we're
treating EAGAIN as a fatal error inside of
svn_ra_serf__context
On Tue, Jun 12, 2012 at 8:22 AM, Justin Erenkrantz
wrote:
> On Tuesday, June 12, 2012, C. Michael Pilato wrote:
>> On 06/10/2012 09:13 AM, Justin Erenkrantz wrote:
>> > How does the user recover? Less of an issue when we have WC-specific
>> > pristines, but itis more of an issue as we move toward
38 matches
Mail list logo
