Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@subversion.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Subject: Re: svn commit: r1150368 - in
 /subversion/trunk/subversion/libsvn_client: commit.c commit_util.c
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset=us-ascii
From: Blair Zajac <blair@orcaware.com>
In-Reply-To: <20110724135045.66B1E238885D@eris.apache.org>
Date: Sun, 24 Jul 2011 07:08:53 -0700
Cc: commits@subversion.apache.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <14985990-FD50-4C69-AA8C-7C06D509DED9@orcaware.com>
References: <20110724135045.66B1E238885D@eris.apache.org>
To: dev@subversion.apache.org


On Jul 24, 2011, at 6:50 AM, rhuijben@apache.org wrote:

> Author: rhuijben
> Date: Sun Jul 24 13:50:44 2011
> New Revision: 1150368
>=20
> URL: http://svn.apache.org/viewvc?rev=3D1150368&view=3Drev
> Log:
> Clear iterpools in two error conditions during commit to avoid =
deleting files
> with open handles when aborting fs transactions.
>=20
> The txdelta part of this patch looks like a small regression =
introduced by
> switching from subpools to dual pool handling.
>=20
> * subversion/libsvn_client/commit.c
>  (svn_client_commit5): Clear iterpool before aborting the edit to =
flush the
>    most commonly passed scratch pool to the commit processing. This to =
avoid
>    possible similar problems as that caught in svn_client__do_commit.
>=20
> * subversion/libsvn_client/commit_util.c
>  (svn_client__do_commit): Clear iterpool when =
svn_wc_transmit_text_deltas3
>    fails. The txdelta infrastructure doesn't have a well defined abort
>    procedure so the current implementations rely on pool cleanup.
>    But when iterpool isn't cleared here we call the editor's abort =
before
>    this cleanup runs.

Do you mean destroy here, as that's what the commit does?

Blair