Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ABBAF17EE9 for ; Mon, 20 Oct 2014 12:34:56 +0000 (UTC) Received: (qmail 55680 invoked by uid 500); 20 Oct 2014 12:34:56 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 55618 invoked by uid 500); 20 Oct 2014 12:34:56 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 55608 invoked by uid 99); 20 Oct 2014 12:34:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Oct 2014 12:34:56 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of stefan.fuhrmann@wandisco.com designates 209.85.223.171 as permitted sender) Received: from [209.85.223.171] (HELO mail-ie0-f171.google.com) (209.85.223.171) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Oct 2014 12:34:30 +0000 Received: by mail-ie0-f171.google.com with SMTP id tr6so4557818ieb.16 for ; Mon, 20 Oct 2014 05:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wandisco.com; s=gapps; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+FNnaLtlYRlXE1hj+D7HBX01SI2wwcsfK/8UHwp8CTg=; b=IZHnUpUWL414BYCtzqpG5btJxBtrd/7bUNvoyq6EhWk6+r2xjQal5sbHQMLFy536TK OywRPxeU+GkuDtdAWluTebJtTHnfH37qrGvrnNOMvJOSeceQTdYhz3Xsx/4/tzzxTXlp qfm+8a1UGnc5t45JmZXo0bTL2c83YleM6942s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+FNnaLtlYRlXE1hj+D7HBX01SI2wwcsfK/8UHwp8CTg=; b=TXwLiJkoTgfKfBmdT49F1cIcugqLch2X+U+srY/jtdbgruVXA3c9fAI335Vn73J0wB rNokxe3TcpsQ7Hzy8YidrlWaZk4miciQaa2AULESScQoqtSOu7xuKBPRWjpuRdYCwVek 40L+6d2Pj8nKDWdTaqQyQi8YNLOKQe5krfjdWJSc0P7koqQaaMX7cFWrC27jHAwtT4/m QHL2kJDQd3hGbA7U3mtW2t4U7EqnquzyPVuYkjR3Wxxd/Vp3TofGa0FJuFs907xaDdyP WzFM/INaKt/dpTE3Fm0+sP/UO/Z/XoJi2Ecqka3MMVWTmOLzsnaPFfEh7UuugzKDkuDV CFiA== X-Gm-Message-State: ALoCoQkmgbwGcffAJad84ip1pEW6RAglXGSaEBbED6hy1xwHgbG/NJcACTAp/nTP22c3ofsE2eq4 MIME-Version: 1.0 X-Received: by 10.51.16.65 with SMTP id fu1mr18143201igd.18.1413808468240; Mon, 20 Oct 2014 05:34:28 -0700 (PDT) Received: by 10.50.224.138 with HTTP; Mon, 20 Oct 2014 05:34:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Oct 2014 14:34:28 +0200 Message-ID: Subject: Re: named_atomic tests failures on Windows From: Stefan Fuhrmann To: Ivan Zhakov Cc: Subversion Development Content-Type: multipart/alternative; boundary=001a1135f32e87c7730505d9efe4 X-Virus-Checked: Checked by ClamAV on apache.org --001a1135f32e87c7730505d9efe4 Content-Type: text/plain; charset=UTF-8 On Tue, Sep 23, 2014 at 12:31 PM, Stefan Fuhrmann < stefan.fuhrmann@wandisco.com> wrote: > > On Thu, Sep 18, 2014 at 3:00 PM, Ivan Zhakov wrote: > >> On 11 September 2014 20:28, Stefan Fuhrmann >> wrote: >> > On Wed, Sep 10, 2014 at 5:35 PM, Ivan Zhakov >> wrote: >> > >> 2. Remove it since "named atomics" framework is only used for currently >> >> disabled revprop caching. >> > >> > >> > ... I'm +1 on getting rid of the SHM code altogether (we are using MMAP >> to >> > get shared memory). It turned out to be a poor choice as all sorts of >> > Windows >> > platform specifics make it hard caused us to deviate further and further >> > from >> > the initial APR-based design. Some of the Windows-specific issues, e.g. >> the >> > file retry races in the init code, should have been reported before the >> > 1.8.0 >> > release. >> > >> >> >> >> Personally I don't see reason to spend resources fixing unused code, >> >> especially >> >> that even code on 'revprop-caching-ng' branch removes it also. Any >> >> other opinions? >> > >> > >> > No, I agree. >> > >> > The revpro-caching-ng branch pretty much exactly removes the SHM >> > code. >> I think that the revprop-caching-ng branch should not be merged. So >> may be worth to remove named-atomics and SHM code from trunk to turn >> the trunk back to the normal state (without unused and not working code) >> > > Here is what I will do on /trunk: > > * Merge the new revprop caching scheme to FSX. > Done in r1632907,-9. * Remove the SHM-dependent bits from FSFS but keep the actual > cache invocations (no-ops since there is no cache instance) at least > for now. > Done in r1632926. * Remove the named_atomics code. > Done in r1632936. > * Update the revprop-caching-ng branch > Done in r1632945. > Why do you think the revprop-caching-ng branch should not be merged? > > -- Stefan^2. > --001a1135f32e87c7730505d9efe4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Sep 23, 2014 at 12:31 PM, Stefan Fuhrmann <stefan.fuhrm= ann@wandisco.com> wrote:

On Thu, Sep 18, 2014 at 3:00 P= M, Ivan Zhakov <ivan@visualsvn.com> wrote:
On 11 September 2014 20:28, Stefan Fuh= rmann
<stefan.fuhrmann@wandisco.com> wrote:
> On Wed, Sep 10, 2014 at 5:35 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:
>> 2. Remove it since "named atomics" framework is on= ly used for currently
>>=C2=A0 =C2=A0 disabled revprop caching.
>
>
> ... I'm +1 on getting rid of the SHM code altogether (we are using= MMAP to
> get shared memory). It turned out to be a poor choice as all sorts of<= br> > Windows
> platform specifics make it hard caused us to deviate further and furth= er
> from
> the initial APR-based design. Some of the Windows-specific issues, e.g= . the
> file retry races in the init code, should have been reported before th= e
> 1.8.0
> release.
>
>>
>> Personally I don't see reason to spend resources = fixing unused code,
>> especially
>> that even code on 'revprop-caching-ng' branch removes it a= lso. Any
>> other opinions?
>
>
> No, I agree.
>
> The revpro-caching-ng branch pretty much exactly removes the SHM
> code.
I think that the revprop-caching-ng branch should not be merged. So<= br> may be worth to remove named-atomics and SHM code from trunk to turn
the trunk back to the normal state (without unused and not working code)

Here is what I will do on /trunk:

* Merge the new revprop caching scheme to FSX= .
=C2=A0
Done in r1632907,= -9.

= * Remove the SHM-dependent bits from FSFS but keep the actual
=C2=A0 cache invocations (no-ops since there is no c= ache instance) at least
=C2=A0 for now.=

Done in r1632926.

=C2=A0*= Remove the named_atomics code.

=
Done in r1632936.
=C2=A0
* Update the revprop-caching-ng branch=

Done in r1632945.
=C2=A0=C2=A0
Why do you think the revprop-c= aching-ng branch should not be merged?

-- Stefan^2.
<= /div>

--001a1135f32e87c7730505d9efe4--