You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lieven Govaerts <sv...@mobsol.be> on 2011/01/21 00:18:20 UTC
Re: [serf-dev] Re: What stands between us and branching 1.7?
On Thu, Jan 13, 2011 at 9:15 AM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
> On Thu, Jan 6, 2011 at 1:04 PM, C. Michael Pilato <cm...@collab.net>
> wrote:
> > On 01/06/2011 03:48 PM, Stefan Küng wrote:
> >> On 06.01.2011 21:41, C. Michael Pilato wrote:
> >>> I'm sorry if I asked this before -- I've been asking individual folks
> for
> >>> over a month now, but I can't quickly find a public broadcast thread
> about
> >>> it, at least -- but I've been wondering lately:
> >>>
> >>> What, exactly, stands in the way of us branching for 1.7
> stabilization?
> >>>
> >>> ra_serf stabilization? No... that's fairly well taken care of, and
> would
> >>> fit perfectly within in the scope of post-branch work anyway.
> >>
> >> At least on Windows, I doubt that ra_serf is even used right now.
> Because of
> >> the huge memory leak serf has/had (See here:
> >> http://code.google.com/p/serf/source/detail?r=1416). But even though
> the
> >> leak is fixed, there hasn't been another release yet.
> >> With the latest release without that fix, serf is not usable at all.
> >> To get more people to test ra_serf, serf itself first needs a new
> release
> >> which includes that fix.
> >>
> >> Stefan
> >>
> >
> > Xlnt feedback. I've noted this on our roadmap.html page. What else?
>
> We could cut a serf bug fix release that has a few fixes that Lieven
> committed shortly after we released 0.7.0.
Greg or Lieven, any thoughts here? -- justin
At least the one rev that fixes this issue, don't know if the other are
already working in all scenario's.
I'll look at it this weekend and make a release.
Lieven
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jan 23, 2011 at 5:41 AM, Lieven Govaerts <sv...@mobsol.be> wrote:
> I'd appreciate some more testing, before I make the release later this week.
> The code to get is:
> http://serf.googlecode.com/svn/branches/0.7.x at r1427.
% uname -v
Darwin Kernel Version 10.5.0: Fri Nov 5 23:20:39 PDT 2010;
root:xnu-1504.9.17~1/RELEASE_I386
(OS X 10.6.5)
% ln -s ~/work/serf-0.7.x/test/serftestca.pem test/serftestca.pem
(I use VPATH builds, so had to bring over serftestca.pem into the
build dir to get the 2 SSL tests to pass)
% ./test/test_all
.................
OK (17 tests)
And, 0.7.x builds fine against latest SVN 1.6.x branches and basic
co/ls functionality via ra_serf seems good.
Looks good! Thanks! -- justin
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Stefan Sperling <st...@elego.de>.
On Sun, Jan 23, 2011 at 02:41:49PM +0100, Lieven Govaerts wrote:
> On Fri, Jan 21, 2011 at 7:59 AM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
>
> > On Thu, Jan 20, 2011 at 3:18 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
> > >> Greg or Lieven, any thoughts here? -- justin
> > >
> > > At least the one rev that fixes this issue, don't know if the other are
> > > already working in all scenario's.
> > > I'll look at it this weekend and make a release.
> >
> > Woohoo. Thanks. I'll be sure to test it. Let me know if you need
> > any help. -- justin
> >
>
> I've prepared branch 0.7.x with the changes that are safe to go in serf
> 0.7.1.
>
> I'm running some tests on Linux, Windows 7 and Mac Os X. On the latter svn
> trunk currently doesn't build for me (is_atomicity_error symbol not found),
> but doesn't seem to be related to serf.
>
> I'd appreciate some more testing, before I make the release later this week.
> The code to get is:
> http://serf.googlecode.com/svn/branches/0.7.x at r1427.
The svn-openbsd-i386 buildbot is using serf 0.7.x. The working copy
isn't updated automatically, but I've just removed it so it should get
a fresh checkout during the next build and run all tests with the
newest serf.
Stean
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Lieven Govaerts wrote on Sun, Jan 23, 2011 at 14:41:49 +0100:
> I'm running some tests on Linux, Windows 7 and Mac Os X. On the latter svn
> trunk currently doesn't build for me (is_atomicity_error symbol not found),
> but doesn't seem to be related to serf.
That's odd: in HEAD, that symbol only appears in ra/util.c, and it's
declared "static" there.
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Stefan Küng <to...@gmail.com>.
On 23.01.2011 18:06, Justin Erenkrantz wrote:
> On Sun, Jan 23, 2011 at 8:42 AM, Stefan Küng<to...@gmail.com> wrote:
>> Ok, tested with serf from the 0.7.x branch: memory rise is still higher than
>> with neon, indicating that there's still some (small) memory leak somewhere.
>> But checkouts and updates of even larger projects succeed without using up
>> all available memory as before.
>> To compare: checkout of the TSVN source including all externals with serf
>> uses up about 40MB more RAM than when using neon. I'd say that's ok.
>
> Does the memory keep going up? Or, does it reach a steady point? I'd
> expect that ra_serf would use a bit more memory than ra_neon as it has
> to manage a lot more than what neon has to do.
>
> As a point of reference, on Mac OS X 10.6, svn 1.6.x with ra_serf
> checking out svn trunk peaks at 81MB, while ra_neon peaks at 12MB.
I can't really say for sure if serf memory keeps going up or not. I was
testing with TSVN and there the memory has to keep going up since all
the output is stored in memory for the UI controls to show to the user.
I can only say for sure that the memory for both neon and serf goes up
at approximately the same rate. Only with serf, memory goes up at the
beginning very fast until about 40-50MB more than with neon, but then
keeps that 'distance' (well, almost: the distance increases a little
bit, but not much - around 8kbytes per two seconds) to neon until the end.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/24/2011 02:20 AM, Lieven Govaerts wrote:
> Linking the file pool to the pool of its parent dir has resulted in crashes
> earlier. I seem to remember it's because the files are received after the
> dir is already closed in the editor drive, but I don't remember all the details.
I can't speak directly to the code in the question, but it is valid to drive
an editor such that file batons outlive all directory batons. Generally
speaking, file-specific pools in editor implementations should probably be
children of the editor-global pool (and remain as lightweight as possible).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Sun, Jan 23, 2011 at 8:39 PM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
> On Sun, Jan 23, 2011 at 10:22 AM, Lieven Govaerts <sv...@mobsol.be>
> wrote:
> > Things have changed since then though. Can anyone test with svn 1.6.x to
> see
> > how it uses memory?
>
> For ra_serf, I'm wondering if we're creating an additional pool that
> isn't necessary - namely the editor_pool.
>
> I've done some light testing with the ra_serf patch below, which does
> the following things:
> - Create a separate pool hierarchy for files
> - Combines the per-file editor pool with the regular pool for file
>
> For serf itself, I've also switched zlib to use the bucket allocator -
> which also helps which churn - as every call to inflateInit/inflateEnd
> invokes malloc/free - so we can save on that quite bit.
>
> Overall, this seems to reduce the amount of 20KB allocations
> substantially...but not sure it does much to the overall memory usage.
>
> Not sure if/when I'll pick this up again...so patches below if someone
> else wants to run with it. -- justin
>
> Index: update.c
> ===================================================================
> --- update.c (revision 1062462)
> +++ update.c (working copy)
> @@ -107,6 +107,7 @@
> /* controlling dir baton - this is only created in open_dir() */
> void *dir_baton;
> apr_pool_t *dir_baton_pool;
> + apr_pool_t *file_pool;
>
> /* Our master update editor and baton. */
> const svn_delta_editor_t *update_editor;
> @@ -202,9 +203,6 @@
> /* The properties for this file */
> apr_hash_t *props;
>
> - /* pool passed to update->add_file, etc. */
> - apr_pool_t *editor_pool;
> -
> /* controlling file_baton and textdelta handler */
> void *file_baton;
> const char *base_checksum;
> @@ -403,7 +401,7 @@
> report_info_t *new_info;
>
> new_info = apr_pcalloc(info_parent_pool, sizeof(*new_info));
> - apr_pool_create(&new_info->pool, info_parent_pool);
> + apr_pool_create(&new_info->pool, info->dir->file_pool);
> new_info->file_baton = NULL;
> new_info->lock_token = NULL;
> new_info->fetch_file = FALSE;
> @@ -500,6 +498,7 @@
> if (dir->base_name[0] == '\0')
> {
> apr_pool_create(&dir->dir_baton_pool, dir->pool);
> + apr_pool_create(&dir->file_pool, dir->pool);
>
> if (dir->report_context->destination &&
> dir->report_context->sess->wc_callbacks->invalidate_wc_props)
> @@ -519,6 +518,7 @@
> SVN_ERR(open_dir(dir->parent_dir));
>
> apr_pool_create(&dir->dir_baton_pool,
> dir->parent_dir->dir_baton_pool);
> + dir->file_pool = dir->parent_dir->file_pool;
>
>
Linking the file pool to the pool of its parent dir has resulted in crashes
earlier. I seem to remember it's because the files are received after the
dir is already closed in the editor drive, but I don't remember all the
details.
Lieven
[..]
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jan 23, 2011 at 10:22 AM, Lieven Govaerts <sv...@mobsol.be> wrote:
> Things have changed since then though. Can anyone test with svn 1.6.x to see
> how it uses memory?
For ra_serf, I'm wondering if we're creating an additional pool that
isn't necessary - namely the editor_pool.
I've done some light testing with the ra_serf patch below, which does
the following things:
- Create a separate pool hierarchy for files
- Combines the per-file editor pool with the regular pool for file
For serf itself, I've also switched zlib to use the bucket allocator -
which also helps which churn - as every call to inflateInit/inflateEnd
invokes malloc/free - so we can save on that quite bit.
Overall, this seems to reduce the amount of 20KB allocations
substantially...but not sure it does much to the overall memory usage.
Not sure if/when I'll pick this up again...so patches below if someone
else wants to run with it. -- justin
Index: update.c
===================================================================
--- update.c (revision 1062462)
+++ update.c (working copy)
@@ -107,6 +107,7 @@
/* controlling dir baton - this is only created in open_dir() */
void *dir_baton;
apr_pool_t *dir_baton_pool;
+ apr_pool_t *file_pool;
/* Our master update editor and baton. */
const svn_delta_editor_t *update_editor;
@@ -202,9 +203,6 @@
/* The properties for this file */
apr_hash_t *props;
- /* pool passed to update->add_file, etc. */
- apr_pool_t *editor_pool;
-
/* controlling file_baton and textdelta handler */
void *file_baton;
const char *base_checksum;
@@ -403,7 +401,7 @@
report_info_t *new_info;
new_info = apr_pcalloc(info_parent_pool, sizeof(*new_info));
- apr_pool_create(&new_info->pool, info_parent_pool);
+ apr_pool_create(&new_info->pool, info->dir->file_pool);
new_info->file_baton = NULL;
new_info->lock_token = NULL;
new_info->fetch_file = FALSE;
@@ -500,6 +498,7 @@
if (dir->base_name[0] == '\0')
{
apr_pool_create(&dir->dir_baton_pool, dir->pool);
+ apr_pool_create(&dir->file_pool, dir->pool);
if (dir->report_context->destination &&
dir->report_context->sess->wc_callbacks->invalidate_wc_props)
@@ -519,6 +518,7 @@
SVN_ERR(open_dir(dir->parent_dir));
apr_pool_create(&dir->dir_baton_pool, dir->parent_dir->dir_baton_pool);
+ dir->file_pool = dir->parent_dir->file_pool;
if (SVN_IS_VALID_REVNUM(dir->base_rev))
{
@@ -632,7 +632,7 @@
if (lock_val)
{
char *new_lock;
- new_lock = apr_pstrdup(info->editor_pool, lock_val);
+ new_lock = apr_pstrdup(info->pool, lock_val);
apr_collapse_spaces(new_lock, new_lock);
lock_val = new_lock;
}
@@ -641,7 +641,7 @@
{
svn_string_t *str;
- str = svn_string_ncreate("", 1, info->editor_pool);
+ str = svn_string_ncreate("", 1, info->pool);
svn_ra_serf__set_ver_prop(info->dir->removed_props, info->base_name,
info->base_rev, "DAV:", "lock-token",
@@ -756,13 +756,11 @@
return error_fetch(request, fetch_ctx, err);
}
- apr_pool_create(&info->editor_pool, info->dir->dir_baton_pool);
-
/* Expand our full name now if we haven't done so yet. */
if (!info->name)
{
info->name_buf = svn_stringbuf_dup(info->dir->name_buf,
- info->editor_pool);
+ info->pool);
svn_path_add_component(info->name_buf, info->base_name);
info->name = info->name_buf->data;
}
@@ -772,7 +770,7 @@
err = info->dir->update_editor->open_file(info->name,
info->dir->dir_baton,
info->base_rev,
- info->editor_pool,
+ info->pool,
&info->file_baton);
}
else
@@ -781,7 +779,7 @@
info->dir->dir_baton,
info->copyfrom_path,
info->copyfrom_rev,
- info->editor_pool,
+ info->pool,
&info->file_baton);
}
@@ -792,7 +790,7 @@
err = info->dir->update_editor->apply_textdelta(info->file_baton,
info->base_checksum,
- info->editor_pool,
+ info->pool,
&info->textdelta,
&info->textdelta_baton);
@@ -806,7 +804,7 @@
fetch_ctx->delta_stream =
svn_txdelta_parse_svndiff(info->textdelta,
info->textdelta_baton,
- TRUE, info->editor_pool);
+ TRUE, info->pool);
}
else
{
@@ -922,24 +920,24 @@
info->base_name,
info->base_rev,
set_file_props,
- info, info->editor_pool);
+ info, info->pool);
svn_ra_serf__walk_all_props(info->dir->removed_props,
info->base_name,
info->base_rev,
remove_file_props,
- info, info->editor_pool);
+ info, info->pool);
if (info->fetch_props)
{
svn_ra_serf__walk_all_props(info->props,
info->url,
info->target_rev,
set_file_props,
- info, info->editor_pool);
+ info, info->pool);
}
err = info->dir->update_editor->close_file(info->file_baton,
info->final_checksum,
- info->editor_pool);
+ info->pool);
if (err)
{
@@ -953,7 +951,6 @@
*fetch_ctx->done_list = &fetch_ctx->done_item;
/* We're done with our pools. */
- svn_pool_destroy(info->editor_pool);
svn_pool_destroy(info->pool);
return status;
@@ -1055,13 +1052,11 @@
/* Ensure our parent is open. */
SVN_ERR(open_dir(info->dir));
- apr_pool_create(&info->editor_pool, info->dir->dir_baton_pool);
-
/* Expand our full name now if we haven't done so yet. */
if (!info->name)
{
info->name_buf = svn_stringbuf_dup(info->dir->name_buf,
- info->editor_pool);
+ info->pool);
svn_path_add_component(info->name_buf, info->base_name);
info->name = info->name_buf->data;
}
@@ -1071,7 +1066,7 @@
SVN_ERR(info->dir->update_editor->open_file(info->name,
info->dir->dir_baton,
info->base_rev,
- info->editor_pool,
+ info->pool,
&info->file_baton));
}
else
@@ -1080,7 +1075,7 @@
info->dir->dir_baton,
info->copyfrom_path,
info->copyfrom_rev,
- info->editor_pool,
+ info->pool,
&info->file_baton));
}
@@ -1088,7 +1083,7 @@
{
SVN_ERR(info->dir->update_editor->apply_textdelta(info->file_baton,
info->base_checksum,
- info->editor_pool,
+ info->pool,
&info->textdelta,
&info->textdelta_baton));
}
@@ -1099,22 +1094,21 @@
/* set all of the properties we received */
svn_ra_serf__walk_all_props(info->props,
info->base_name, info->base_rev,
- set_file_props, info, info->editor_pool);
+ set_file_props, info, info->pool);
svn_ra_serf__walk_all_props(info->dir->removed_props,
info->base_name, info->base_rev,
- remove_file_props, info, info->editor_pool);
+ remove_file_props, info, info->pool);
if (info->fetch_props)
{
svn_ra_serf__walk_all_props(info->props, info->url, info->target_rev,
- set_file_props, info, info->editor_pool);
+ set_file_props, info, info->pool);
}
SVN_ERR(info->dir->update_editor->close_file(info->file_baton,
info->final_checksum,
- info->editor_pool));
+ info->pool));
/* We're done with our pools. */
- svn_pool_destroy(info->editor_pool);
svn_pool_destroy(info->pool);
info->dir->ref_count--;
(serf)
Index: buckets/deflate_buckets.c
===================================================================
--- buckets/deflate_buckets.c (revision 1427)
+++ buckets/deflate_buckets.c (working copy)
@@ -78,6 +78,18 @@
| (((unsigned long)string[3]) << 24);
}
+voidpf _alloc_zlib(voidpf opaque, unsigned items, unsigned size)
+{
+ serf_bucket_alloc_t *allocator = (serf_bucket_alloc_t*)opaque;
+ return serf_bucket_mem_alloc(allocator, items * size);
+}
+
+void _free_zlib(voidpf opaque, voidpf ptr)
+{
+ serf_bucket_alloc_t *allocator = (serf_bucket_alloc_t*)opaque;
+ serf_bucket_mem_free(allocator, ptr);
+}
+
serf_bucket_t *serf_bucket_deflate_create(
serf_bucket_t *stream,
serf_bucket_alloc_t *allocator,
@@ -93,6 +105,9 @@
ctx->crc = 0;
/* zstream must be NULL'd out. */
memset(&ctx->zstream, 0, sizeof(ctx->zstream));
+ ctx->zstream.opaque = allocator;
+ ctx->zstream.zalloc = _alloc_zlib;
+ ctx->zstream.zfree = _free_zlib;
switch (ctx->format) {
case SERF_DEFLATE_GZIP:
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Sun, Jan 23, 2011 at 6:06 PM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
> On Sun, Jan 23, 2011 at 8:42 AM, Stefan Küng <to...@gmail.com>
> wrote:
> > Ok, tested with serf from the 0.7.x branch: memory rise is still higher
> than
> > with neon, indicating that there's still some (small) memory leak
> somewhere.
> > But checkouts and updates of even larger projects succeed without using
> up
> > all available memory as before.
> > To compare: checkout of the TSVN source including all externals with serf
> > uses up about 40MB more RAM than when using neon. I'd say that's ok.
>
> Does the memory keep going up? Or, does it reach a steady point? I'd
> expect that ra_serf would use a bit more memory than ra_neon as it has
> to manage a lot more than what neon has to do.
>
> As a point of reference, on Mac OS X 10.6, svn 1.6.x with ra_serf
> checking out svn trunk peaks at 81MB, while ra_neon peaks at 12MB.
>
I have been looking at ra_serf's memory usage with svn trunk at the last svn
days in Berlin and found that most memory was allocated and held in the
sqlite code.
Things have changed since then though. Can anyone test with svn 1.6.x to see
how it uses memory?
Lieven
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sun, Jan 23, 2011 at 8:42 AM, Stefan Küng <to...@gmail.com> wrote:
> Ok, tested with serf from the 0.7.x branch: memory rise is still higher than
> with neon, indicating that there's still some (small) memory leak somewhere.
> But checkouts and updates of even larger projects succeed without using up
> all available memory as before.
> To compare: checkout of the TSVN source including all externals with serf
> uses up about 40MB more RAM than when using neon. I'd say that's ok.
Does the memory keep going up? Or, does it reach a steady point? I'd
expect that ra_serf would use a bit more memory than ra_neon as it has
to manage a lot more than what neon has to do.
As a point of reference, on Mac OS X 10.6, svn 1.6.x with ra_serf
checking out svn trunk peaks at 81MB, while ra_neon peaks at 12MB.
HTH. -- justin
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Stefan Küng <to...@gmail.com>.
On 23.01.2011 16:09, Lieven Govaerts wrote:
> I've used a build from serf trunk for a while now without problems.
> The serf log indicates that r1416 has been merged, but r1417 has
> not. Is there a reason why this memory leak fix hasn't been merged
> to 0.7.x?
>
>
> r1417 is part of a refactoring on trunk to move the connection related
> code in a separate bucket (httpconn). I doubt that that code is really
> stable yet, so I'd rather not merge it to 0.7.x.
Ok, tested with serf from the 0.7.x branch: memory rise is still higher
than with neon, indicating that there's still some (small) memory leak
somewhere. But checkouts and updates of even larger projects succeed
without using up all available memory as before.
To compare: checkout of the TSVN source including all externals with
serf uses up about 40MB more RAM than when using neon. I'd say that's ok.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Sun, Jan 23, 2011 at 3:59 PM, Stefan Küng <to...@gmail.com> wrote:
> On 23.01.2011 14:41, Lieven Govaerts wrote:
>
>>
>>
>> On Fri, Jan 21, 2011 at 7:59 AM, Justin Erenkrantz
>> <justin@erenkrantz.com <ma...@erenkrantz.com>> wrote:
>>
>> On Thu, Jan 20, 2011 at 3:18 PM, Lieven Govaerts <svnlgo@mobsol.be
>> <ma...@mobsol.be>> wrote:
>> >> Greg or Lieven, any thoughts here? -- justin
>> >
>> > At least the one rev that fixes this issue, don't know if the
>> other are
>> > already working in all scenario's.
>> > I'll look at it this weekend and make a release.
>>
>> Woohoo. Thanks. I'll be sure to test it. Let me know if you need
>> any help. -- justin
>>
>>
>> I've prepared branch 0.7.x with the changes that are safe to go in serf
>> 0.7.1.
>>
>> I'm running some tests on Linux, Windows 7 and Mac Os X. On the latter
>> svn trunk currently doesn't build for me (is_atomicity_error symbol not
>> found), but doesn't seem to be related to serf.
>>
>> I'd appreciate some more testing, before I make the release later this
>> week. The code to get is:
>> http://serf.googlecode.com/svn/branches/0.7.x at r1427.
>>
>
> I've used a build from serf trunk for a while now without problems.
> The serf log indicates that r1416 has been merged, but r1417 has not. Is
> there a reason why this memory leak fix hasn't been merged to 0.7.x?
r1417 is part of a refactoring on trunk to move the connection related code
in a separate bucket (httpconn). I doubt that that code is really stable
yet, so I'd rather not merge it to 0.7.x.
Lieven
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Stefan Küng <to...@gmail.com>.
On 23.01.2011 14:41, Lieven Govaerts wrote:
>
>
> On Fri, Jan 21, 2011 at 7:59 AM, Justin Erenkrantz
> <justin@erenkrantz.com <ma...@erenkrantz.com>> wrote:
>
> On Thu, Jan 20, 2011 at 3:18 PM, Lieven Govaerts <svnlgo@mobsol.be
> <ma...@mobsol.be>> wrote:
> >> Greg or Lieven, any thoughts here? -- justin
> >
> > At least the one rev that fixes this issue, don't know if the
> other are
> > already working in all scenario's.
> > I'll look at it this weekend and make a release.
>
> Woohoo. Thanks. I'll be sure to test it. Let me know if you need
> any help. -- justin
>
>
> I've prepared branch 0.7.x with the changes that are safe to go in serf
> 0.7.1.
>
> I'm running some tests on Linux, Windows 7 and Mac Os X. On the latter
> svn trunk currently doesn't build for me (is_atomicity_error symbol not
> found), but doesn't seem to be related to serf.
>
> I'd appreciate some more testing, before I make the release later this
> week. The code to get is:
> http://serf.googlecode.com/svn/branches/0.7.x at r1427.
I've used a build from serf trunk for a while now without problems.
The serf log indicates that r1416 has been merged, but r1417 has not. Is
there a reason why this memory leak fix hasn't been merged to 0.7.x?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Lieven Govaerts <sv...@mobsol.be>.
On Fri, Jan 21, 2011 at 7:59 AM, Justin Erenkrantz <ju...@erenkrantz.com>wrote:
> On Thu, Jan 20, 2011 at 3:18 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
> >> Greg or Lieven, any thoughts here? -- justin
> >
> > At least the one rev that fixes this issue, don't know if the other are
> > already working in all scenario's.
> > I'll look at it this weekend and make a release.
>
> Woohoo. Thanks. I'll be sure to test it. Let me know if you need
> any help. -- justin
>
I've prepared branch 0.7.x with the changes that are safe to go in serf
0.7.1.
I'm running some tests on Linux, Windows 7 and Mac Os X. On the latter svn
trunk currently doesn't build for me (is_atomicity_error symbol not found),
but doesn't seem to be related to serf.
I'd appreciate some more testing, before I make the release later this week.
The code to get is:
http://serf.googlecode.com/svn/branches/0.7.x at r1427.
Lieven
Re: [serf-dev] Re: What stands between us and branching 1.7?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Jan 20, 2011 at 3:18 PM, Lieven Govaerts <sv...@mobsol.be> wrote:
>> Greg or Lieven, any thoughts here? -- justin
>
> At least the one rev that fixes this issue, don't know if the other are
> already working in all scenario's.
> I'll look at it this weekend and make a release.
Woohoo. Thanks. I'll be sure to test it. Let me know if you need
any help. -- justin