On Mon, Sep 14, 2009 at 2:48 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> On Mon, Sep 14, 2009 at 9:09 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Mon, Sep 14, 2009 at 8:57 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> Paul, I am going to assume this one is for you as I believe you are
>>> working on it.
>>> It looks like anywhere we call the svn_client_suggest_merge_sources
>>> API from JavaHL we get this error. When Java is running SVN API, the
>>> current working directory is unlikely to be set to the working copy
>>> folder. It looks like maybe somewhere it is making that assumption?
>>> Note that the path mentioned is my trunk working copy, not the one for
>>> the tests.
>> As an additional bit of information, if I set the current directory to
>> a path that is not a working copy before the tests run, then it does
>> not get any errors and the tests continue.
>> Mark Phippard
> This failure is traceable back to r38734 which directly fetched an
> entry instead of using an access baton and relied on the error
> returned when fetching the entry to detect the root of the working
> copy. Problem is this is not a very robust way to detect the WC root.
> In your particular case, where the root of the WC is in a directory
> that is an immediate child of *another* unlrelated WC, the
> call to svn_wc__get_entry_versioned() thinks the parent of the WC root
> is actually an unversioned path in the encompassing WC
> (/Users/mphippard/work/src-trunk), which, since it is a 1.6.x WC*,
> causes SVN_ERR_WC_UNSUPPORTED_FORMAT error to be returned.
> Anyhow, I fixed r39308 by using svn_wc_is_wc_root2 to detect the root.
> * If /Users/mphippard/work/src-trunk *is* a 1.7 WC then let me know,
> because then something else is going on!
Thanks. Yes your explanation was the case.
Received on 2009-09-14 21:01:58 CEST