subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyrum K Wright <hy...@hyrumwright.org>
Subject Re: svn commit: r1091928 - in /subversion/trunk/subversion: libsvn_client/commit.c tests/cmdline/commit_tests.py
Date Thu, 14 Apr 2011 18:08:35 GMT
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,  <rhuijben@apache.org> wrote:
>> > Author: rhuijben
>> > Date: Wed Apr 13 21:47:24 2011
>> > New Revision: 1091928
>> >
>> > URL: http://svn.apache.org/viewvc?rev=1091928&view=rev
>> > Log:
>> > Fix issue #2381: "Cannot commit multiple WC paths which lack a common
>> parent
>> > directory" by making the commit processor determine which locks it needs
>> in
>> > which working copy.
>>
>> I've not looked at the code, but am just wondering about a theoretical
>> point here.  Could the approach fall victim to the same cause as issue
>> #3242?  Specifically, 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.  (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, doesn'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

Mime
View raw message