Return-Path: 
 <commits-return-10994-apmail-subversion-commits-archive=subversion.apache.org@subversion.apache.org>
Delivered-To: apmail-subversion-commits-archive@minotaur.apache.org
Received: (qmail 15555 invoked from network); 14 Apr 2011 18:09:04 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 14 Apr 2011 18:09:04 -0000
Received: (qmail 41621 invoked by uid 500); 14 Apr 2011 18:09:03 -0000
Delivered-To: apmail-subversion-commits-archive@subversion.apache.org
Received: (qmail 41596 invoked by uid 500); 14 Apr 2011 18:09:03 -0000
Mailing-List: contact commits-help@subversion.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@subversion.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@subversion.apache.org>
List-Post: <mailto:commits@subversion.apache.org>
List-Id: <commits.subversion.apache.org>
Reply-To: dev@subversion.apache.org
Delivered-To: mailing list commits@subversion.apache.org
Received: (qmail 41583 invoked by uid 99); 14 Apr 2011 18:09:03 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 18:09:03 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [209.85.214.43] (HELO mail-bw0-f43.google.com) (209.85.214.43)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Apr 2011 18:08:56 +0000
Received: by bwz14 with SMTP id 14so2495739bwz.16
        for <multiple recipients>; Thu, 14 Apr 2011 11:08:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.22.202 with SMTP id o10mr916642bkb.70.1302804515924; Thu,
 14 Apr 2011 11:08:35 -0700 (PDT)
Received: by 10.204.114.211 with HTTP; Thu, 14 Apr 2011 11:08:35 -0700 (PDT)
X-Originating-IP: [146.6.28.79]
In-Reply-To: <0ba601cbfacc$59773c90$0c65b5b0$@qqmail.nl>
References: <20110413214725.0024C238890A@eris.apache.org>
	<BANLkTimAn+S5H_QJSkQW8WM47CTuET8h9A@mail.gmail.com>
	<0ba601cbfacc$59773c90$0c65b5b0$@qqmail.nl>
Date: Thu, 14 Apr 2011 13:08:35 -0500
Message-ID: <BANLkTinm3oGK128wJJ1U=ivW1xZqy5phiw@mail.gmail.com>
Subject: Re: svn commit: r1091928 - in /subversion/trunk/subversion:
 libsvn_client/commit.c tests/cmdline/commit_tests.py
From: Hyrum K Wright <hyrum@hyrumwright.org>
To: Bert Huijben <bert@qqmail.nl>
Cc: dev@subversion.apache.org, rhuijben@apache.org,
	commits@subversion.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

On Thu, Apr 14, 2011 at 12:49 PM, Bert Huijben <bert@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: donderdag 14 april 2011 17:47
>> To: dev@subversion.apache.org
>> Cc: rhuijben@apache.org; commits@subversion.apache.org
>> Subject: Re: svn commit: r1091928 - in /subversion/trunk/subversion:
>> libsvn_client/commit.c tests/cmdline/commit_tests.py
>>
>> On Wed, Apr 13, 2011 at 4:47 PM, =A0<rhuijben@apache.org> wrote:
>> > Author: rhuijben
>> > Date: Wed Apr 13 21:47:24 2011
>> > New Revision: 1091928
>> >
>> > URL: http://svn.apache.org/viewvc?rev=3D1091928&view=3Drev
>> > Log:
>> > Fix issue #2381: "Cannot commit multiple WC paths which lack a common
>> parent
>> > directory" by making the commit processor determine which locks it nee=
ds
>> in
>> > which working copy.
>>
>> I've not looked at the code, but am just wondering about a theoretical
>> point here. =A0Could the approach fall victim to the same cause as issue
>> #3242? =A0Specifically, if all the commits are done in the same editor
>> drive, and that editor drive is rooted somewhere outside of the
>> readable or writable location for the user doing the commit, would we
>> get authz denials?
>>
>> I can just envision the scenario where users try to commit multiple
>> working copies rooted somewhere they can't write to, and it ends up in
>> all kinds of confusion. =A0(Just another reason to introduce the eXecute
>> bit in our authz paradigm...)
>
> By default commit works exactly as before. It's just that you can pass
> explicit targets from multiple working copies.
>
> Yes, that might give you issue #3242, but like Michael said you can have
> that issue in any tree.
>
> The fact that you can now commit in multiple working copies at once, does=
n't
> say that it is the right thing to do: it's just an option.
> (And in many cases it is NOT the right thing to do)

Oh certainly.  I'm not claiming we should back out this new feature,
just that we should be aware of potential uncertainties that users may
encounter when trying to use it.

FWIW, I had similar concerns about a patch I proposed for issue #1199,
and it never got applied because of them, so I'm a bit sensitive to
this class of issue.  The patch has long since bitrotted. :(  Oh, and
I also coded up the original implementation of issue #3242.  (Not the
fix, the implementation....)

-Hyrum