On Fri, Mar 2, 2012 at 12:52 PM, Philip Martin
<philip.mar...@wandisco.com> wrote:
> Hyrum K Wright <hyrum.wri...@wandisco.com> writes:
>
>>> rm -rf repo wc1 wc2
>>> svnadmin create repo
>>> svn mkdir -mm file://`pwd`/repo/{A,B}
>>> svn co file://`pwd`/repo wc1
>>> svn co file://`pwd`/repo wc2
>>> svn ps p v wc1/A
>>> svn ps p v wc2/B
>>> svn ci -mm wc1 wc2
>>> ../src/subversion/svn/commit-cmd.c:183: (apr_err=155007)
>>> ../src/subversion/libsvn_client/commit.c:874: (apr_err=155007)
>>> ../src/subversion/libsvn_client/commit.c:874: (apr_err=155007)
>>> svn: E155007: Commit failed (details follow):
>>> ../src/subversion/libsvn_client/commit.c:681: (apr_err=155007)
>>> ../src/subversion/libsvn_client/commit.c:681: (apr_err=155007)
>>> ../src/subversion/libsvn_wc/wc_db.c:1560: (apr_err=155007)
>>> ../src/subversion/libsvn_wc/wc_db_wcroot.c:543: (apr_err=155007)
>>> svn: E155007: '/home/pm/sw/subversion/obj' is not a working copy
>>>
>>> svn-1.7 ci -mm wc1 wc2
>>> Sending wc1/A
>>> Sending wc2/B
>>>
>>> Committed revision 2.
>>
>> Yes, the bots give similar output, but my OS X and Ubuntu boxes both
>> seem to have no problems.
>
> The commit works if a grandparent of wc1 and wc2 is a working copy:
>
> wc/ # unrelated working copy
> foo/ # unversioned
> wc1/
> wc2/
>
> It fails if all ancestors are unversioned.
Thanks, that makes the problem easily reproducible.
The core issue here is that we need to provide a way for callbacks to
find their way home to the working copy so they can look up the base
text/props/kind for the Ev2 shims. The only problem is that in this
case, we have a fractured set of working copies, which by design or
accident all manage to get replayed through the same commit editor.
Since the shims operate on a per-editor basis, we don't have a way of
telling them when two switch working copies.
I can squash the error on trunk, and have done so in r1296419 but
we're going to need a long-term solution for this scenario.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
