> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
> Sent: donderdag 14 april 2011 17:47
> To: dev_at_subversion.apache.org
> Cc: rhuijben_at_apache.org; commits_at_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_at_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)
Bert
Received on 2011-04-14 19:50:21 CEST