On Thu, Dec 9, 2021 at 10:32 AM Nathan Hartman <hartman.nat...@gmail.com> wrote:
> So the above can be distilled to:
>
> # .
> # ├── trunk/
> # │ └── c/
> # │ └── d/
> # └── branches
> # └── b/ (from trunk@2)
> # └── c/
>
> It is the 'd' directory ('trunk/c/d/') that is throwing us off course.
As I mentioned before, in diff_dir_added() where that apr_pstrcat()
call happens, right_source->repos_relpath is NULL and my thinking was
that something is forgetting to set it. Long before reaching this
point, there are a few places that seem to come close to setting it
but none do, for reasons that appear reasonable.
So, if I hack diff_dir_added() to force the path to be what I think it
ought to be...
[[[
Index: subversion/libsvn_client/conflicts.c
===================================================================
--- subversion/libsvn_client/conflicts.c (revision 1895966)
+++ subversion/libsvn_client/conflicts.c (working copy)
@@ -7568,7 +7568,7 @@ diff_dir_added(const char *relpath,
SVN_ERR(svn_io_dir_make(local_abspath, APR_OS_DEFAULT, scratch_pool));
copyfrom_url = apr_pstrcat(scratch_pool, b->repos_root_url, "/",
- right_source->repos_relpath, SVN_VA_NULL);
+ "trunk/c/d"
/*right_source->repos_relpath*/, SVN_VA_NULL);
SVN_ERR(svn_wc_add4(b->ctx->wc_ctx, local_abspath, svn_depth_infinity,
copyfrom_url, right_source->revision,
NULL, NULL, /* cancel func/baton */
]]]
...then it appears the call to svn_wc_add4() succeeds -- at least it
doesn't fail.
But immediately after (in diff_dir_added(),
libsvn_client/conflicts.c), we go into a loop that will call
svn_wc_prop_set4() four times. In the first iteration, it tries to set
"svn:entry:committed-rev" despite this foreboding comment in
svn_wc_prop_set4():
/* we don't do entry properties here */
Sure enough, we get:
svn: warning: apr_err=SVN_ERR_BAD_PROP_KIND
svn: warning: W200008: Property 'svn:entry:committed-rev' is an entry property
subversion/svn/merge-cmd.c:556,
subversion/svn/resolve-cmd.c:157: (apr_err=SVN_ERR_WC_CONFLICT_RESOLVER_FAILURE)
svn: E155027: Failure occurred resolving one or more conflicts
Now, this all leads me to believe that something is messed up long
before we get here. What's making this a bigger challenge to debug
than I'd like it to be is all the void pointers to various batons. I
just can't seem to hold in my head the types of more than a few so
quickly lose the ability to trace what comes from where, unless
there's some gdb trick I don't know about that can make it resolve the
correct type.
Anyway I have to pause for today...
Oh one more thing. I believe I succeeded to reproduce the OP's
original issue. If one more subdirectory is added, e.g., trunk/c/d/f,
then f will trigger the same response as the OP reported.
Cheers,
Nathan
