On Wed, May 9, 2012 at 1:34 AM, Ivan Zhakov wrote:
> On Wed, May 9, 2012 at 12:49 AM, C. Michael Pilato
> wrote:
>> On 05/08/2012 04:39 PM, Mark Phippard wrote:
>>> On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov wrote:
On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato
wrote:
> On
On Wed, May 9, 2012 at 12:49 AM, C. Michael Pilato wrote:
> On 05/08/2012 04:39 PM, Mark Phippard wrote:
>> On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov wrote:
>>> On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato
>>> wrote:
On 05/08/2012 03:35 PM, Greg Stein wrote:
> One question: the
On 05/08/2012 04:39 PM, Mark Phippard wrote:
> On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov wrote:
>> On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato
>> wrote:
>>> On 05/08/2012 03:35 PM, Greg Stein wrote:
One question: the ordering of PROPFIND and GET. Do you know if that is
a requi
On Tue, May 8, 2012 at 4:20 PM, Ivan Zhakov wrote:
> On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato
> wrote:
>> On 05/08/2012 03:35 PM, Greg Stein wrote:
>>> One question: the ordering of PROPFIND and GET. Do you know if that is
>>> a requirement, or simply that you were preserving prior beh
On Tue, May 8, 2012 at 11:10 PM, C. Michael Pilato wrote:
> On 05/08/2012 02:20 PM, Ivan Zhakov wrote:
>>> +/* Implements svn_close_fn_t */
>>> +static svn_error_t *
>>> +close_handler_lazyopen(void *baton)
>>> +{
>>> + lazyopen_baton_t *b = baton;
>>> +
>>> + SVN_ERR(lazyopen_if_unopened(b));
>
On Wed, May 9, 2012 at 12:09 AM, C. Michael Pilato wrote:
> On 05/08/2012 03:35 PM, Greg Stein wrote:
>> One question: the ordering of PROPFIND and GET. Do you know if that is
>> a requirement, or simply that you were preserving prior behavior?
>
> Upon reflection, it's probably not a hard require
On Tue, May 8, 2012 at 4:09 PM, C. Michael Pilato wrote:
> On 05/08/2012 03:35 PM, Greg Stein wrote:
>> One question: the ordering of PROPFIND and GET. Do you know if that is
>> a requirement, or simply that you were preserving prior behavior?
>
> Upon reflection, it's probably not a hard requirem
On 05/08/2012 03:35 PM, Greg Stein wrote:
> One question: the ordering of PROPFIND and GET. Do you know if that is
> a requirement, or simply that you were preserving prior behavior?
Upon reflection, it's probably not a hard requirement. In general, I
suppose it's easier (and more efficient) to c
On Tue, May 8, 2012 at 3:23 PM, C. Michael Pilato wrote:
> On 05/08/2012 02:51 PM, Greg Stein wrote:
>> On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato
>> wrote:
>>> As I said before, I suspect your numbers would be much lower if I wasn't
>>> sending HEAD requests for each file. Unfortunately
On 05/08/2012 02:51 PM, Greg Stein wrote:
> On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato wrote:
>> As I said before, I suspect your numbers would be much lower if I wasn't
>> sending HEAD requests for each file. Unfortunately, ra_serf is depending on
>> the ordering of the pipelined requests
On 05/08/2012 02:20 PM, Ivan Zhakov wrote:
>> +/* Implements svn_close_fn_t */
>> +static svn_error_t *
>> +close_handler_lazyopen(void *baton)
>> +{
>> + lazyopen_baton_t *b = baton;
>> +
>> + SVN_ERR(lazyopen_if_unopened(b));
>> + SVN_ERR(svn_stream_close(b->real_stream));
>
> I think we shou
On Tue, May 8, 2012 at 2:49 PM, Mark Phippard wrote:
> On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato wrote:
>> On 05/08/2012 02:34 PM, Mark Phippard wrote:
>>> Now that I can run the test I wanted, the performance improvement is
>>> pretty nice. Checking out our code goes from 1m35s down to
On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato wrote:
> On 05/08/2012 02:34 PM, Mark Phippard wrote:
>> Now that I can run the test I wanted, the performance improvement is
>> pretty nice. Checking out our code goes from 1m35s down to 0m44s. I
>> cannot help but think that number should still
On Tue, May 8, 2012 at 2:45 PM, C. Michael Pilato wrote:
> On 05/08/2012 02:34 PM, Mark Phippard wrote:
>> Now that I can run the test I wanted, the performance improvement is
>> pretty nice. Checking out our code goes from 1m35s down to 0m44s. I
>> cannot help but think that number should still
On Tue, May 8, 2012 at 2:38 PM, C. Michael Pilato wrote:
> On 05/08/2012 02:25 PM, Greg Stein wrote:
>...
>> Per my suggestion on IRC, I don't see how this function can ever
>> error, or ever need a scratch_pool (no matter how we might
>> extend/upgrade it). I'd suggest updating the signature acco
On 05/08/2012 02:34 PM, Mark Phippard wrote:
> Now that I can run the test I wanted, the performance improvement is
> pretty nice. Checking out our code goes from 1m35s down to 0m44s. I
> cannot help but think that number should still be a lot lower though.
> This scenario seems like it would be
On 05/08/2012 02:25 PM, Greg Stein wrote:
> On Tue, May 8, 2012 at 11:06 AM, wrote:
>> ...
>> +++ subversion/trunk/subversion/libsvn_subr/stream.c Tue May 8 15:06:18 2012
>> ...
>> +/* Implements svn_stream_stream_fn_t */
>> +svn_error_t *
>> +svn_stream_lazyopen_create(svn_stream_t **stream,
>>
On Tue, May 8, 2012 at 1:11 PM, C. Michael Pilato wrote:
> On 05/08/2012 01:03 PM, Mark Phippard wrote:
>> On Tue, May 8, 2012 at 12:59 PM, C. Michael Pilato
>> wrote:
>>> Mark, can you see if this (and previous commits I've made) fixes the file
>>> handle abuse problem you reported?
>>>
>>> I t
On Tue, May 8, 2012 at 12:56 PM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/adm_ops.c Tue May 8 16:56:42 2012
>...
> + SVN_ERR(svn_wc__db_pristine_check(&present, wc_ctx->db, wri_abspath,
> + sha1_checksum, scratch_pool));
> +
> + if (present)
>
On Tue, May 8, 2012 at 11:06 AM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_subr/stream.c Tue May 8 15:06:18 2012
>...
> +/* Implements svn_stream_stream_fn_t */
> +svn_error_t *
> +svn_stream_lazyopen_create(svn_stream_t **stream,
> + svn_stream_lazyopen_func
On Tue, May 8, 2012 at 7:06 PM, wrote:
> Author: cmpilato
> Date: Tue May 8 15:06:18 2012
> New Revision: 1335566
>
> URL: http://svn.apache.org/viewvc?rev=1335566&view=rev
> Log:
> Introduce a generic (and as-yet-unused) lazy-open wrapper stream.
>
> * subversion/include/svn_io.h
> (svn_stream
On 05/08/2012 01:03 PM, Mark Phippard wrote:
> On Tue, May 8, 2012 at 12:59 PM, C. Michael Pilato
> wrote:
>> Mark, can you see if this (and previous commits I've made) fixes the file
>> handle abuse problem you reported?
>>
>> I tested this locally using "ulimit -n 200" to reduce the file handle
On Tue, May 8, 2012 at 12:59 PM, C. Michael Pilato wrote:
> On 05/08/2012 12:56 PM, cmpil...@apache.org wrote:
>> Author: cmpilato
>> Date: Tue May 8 16:56:42 2012
>> New Revision: 1335639
>>
>> URL: http://svn.apache.org/viewvc?rev=1335639&view=rev
>> Log:
>> Avoid opening pristine store file ha
On 05/08/2012 12:56 PM, cmpil...@apache.org wrote:
> Author: cmpilato
> Date: Tue May 8 16:56:42 2012
> New Revision: 1335639
>
> URL: http://svn.apache.org/viewvc?rev=1335639&view=rev
> Log:
> Avoid opening pristine store file handles until they are actually
> required.
>
> * subversion/libsvn_
On Tue, May 08, 2012 at 04:42:42PM +0200, Dmitry Pavlenko wrote:
> [[[
> Fix python tests execution for jsvn.
>
> * subversion/tests/cmdline/svntest/main.py
> (execute_tests): svnversion_binary variable was used instead of svnmucc_binary
> ]]]
Obvious fix, thanks. Committed in r133.
>
> [[[
[[[
Fix python tests execution for jsvn.
* subversion/tests/cmdline/svntest/main.py
(execute_tests): svnversion_binary variable was used instead of svnmucc_binary
]]]
[[[
Index: subversion/tests/cmdline/svntest/main.py
===
--- subver
Stefan Sperling wrote on Tue, May 08, 2012 at 13:46:23 +0200:
> On Tue, May 08, 2012 at 02:34:32PM +0300, Daniel Shahaf wrote:
> > The code is #if 0'd because I wanted it when incremental=TRUE but it
> > breaks the incremental=FALSE case. We should remove that temp code and
> > ensure we open DST_
On Tue, May 08, 2012 at 02:34:32PM +0300, Daniel Shahaf wrote:
> Edied the log message in light of these comments.
Cheers!
> The code is #if 0'd because I wanted it when incremental=TRUE but it
> breaks the incremental=FALSE case. We should remove that temp code and
> ensure we open DST_FS and i
Stefan Sperling wrote on Tue, May 08, 2012 at 12:56:46 +0200:
> On Thu, Apr 26, 2012 at 10:04:35PM -, danie...@apache.org wrote:
> > Author: danielsh
> > Date: Thu Apr 26 22:04:34 2012
> > New Revision: 1331125
> >
> > URL: http://svn.apache.org/viewvc?rev=1331125&view=rev
> > Log:
> > Follow-
Stefan Sperling wrote on Tue, May 08, 2012 at 13:00:34 +0200:
> On Thu, Apr 26, 2012 at 07:52:40PM -, danie...@apache.org wrote:
> > Author: danielsh
> > Date: Thu Apr 26 19:52:39 2012
> > New Revision: 1331050
> >
> > URL: http://svn.apache.org/viewvc?rev=1331050&view=rev
> > Log:
> > Store U
On Thu, Apr 26, 2012 at 07:52:40PM -, danie...@apache.org wrote:
> Author: danielsh
> Date: Thu Apr 26 19:52:39 2012
> New Revision: 1331050
>
> URL: http://svn.apache.org/viewvc?rev=1331050&view=rev
> Log:
> Store UUID in svn_fs_t rather than in FSAP_DATA. This improves upon the
> situation
On Thu, Apr 26, 2012 at 10:04:35PM -, danie...@apache.org wrote:
> Author: danielsh
> Date: Thu Apr 26 22:04:34 2012
> New Revision: 1331125
>
> URL: http://svn.apache.org/viewvc?rev=1331125&view=rev
> Log:
> Follow-up to r1331050: try to unbreak the build.
>
> * subversion/libsvn_fs_fs/fs.c
On Tue, May 8, 2012 at 3:59 AM, Johan Corveleyn wrote:
>...
> Though this issue also hits 1.7, it doesn't seem like this is
> something that can be backported easily (with all the recent changes
> to ra_serf), does it? Unless a specific ("quick") fix is made for 1.7?
A backport won't be possible.
On Tue, May 8, 2012 at 3:19 AM, Lieven Govaerts wrote:
> On Tue, May 8, 2012 at 2:29 AM, Greg Stein wrote:
>...
>> My intent is to replace the code you quoted with something basically
>> like: handler->server_error = alloc(). The core response handler will
>> then start processing the body as an
On Tue, May 8, 2012 at 2:29 AM, Greg Stein wrote:
> On May 7, 2012 8:16 PM, "Lieven Govaerts" wrote:
>>...
>> The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
>>
>> if (sl.code == 404 && ctx->ignore_errors == FALSE)
>> {
>> add_done_item(ctx);
>>
>> err = svn_ra_
On Tue, May 8, 2012 at 2:29 AM, Greg Stein wrote:
> On May 7, 2012 8:16 PM, "Lieven Govaerts" wrote:
> >...
> > The problem is in ra_serf/util.c svn_ra_serf__handle_xml_parser:
> >
> > if (sl.code == 404 && ctx->ignore_errors == FALSE)
> > {
> > add_done_item(ctx);
> >
> > err
36 matches
Mail list logo
