On Fri, Apr 27, 2012 at 10:35 PM, Greg Stein <gstein_at_gmail.com> wrote:
> Hey Paul,
>
> I think that I just found a bug in case-only renames, via merge_tests 105.
>
> When the merge -r2:3 is done into the working copy, there are two
> possible outcomes:
>
> GOOD:
> 2012-04-27 22:21:59 [INFO] --- Merging r3 into
> 'svn-test-work/working_copies/merge_tests-105/A_COPY':
> 2012-04-27 22:21:59 [INFO] A
> svn-test-work/working_copies/merge_tests-105/A_COPY/MU
> 2012-04-27 22:21:59 [INFO] D
> svn-test-work/working_copies/merge_tests-105/A_COPY/mu
> 2012-04-27 22:21:59 [INFO] --- Recording mergeinfo for merge of r3
> into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
> 2012-04-27 22:21:59 [INFO] U
> svn-test-work/working_copies/merge_tests-105/A_COPY
>
> BAD:
> 2012-04-27 22:23:27 [INFO] Skipped
> 'svn-test-work/working_copies/merge_tests-105/A_COPY/MU'
> 2012-04-27 22:23:27 [INFO] --- Merging r3 into
> 'svn-test-work/working_copies/merge_tests-105/A_COPY':
> 2012-04-27 22:23:27 [INFO] D
> svn-test-work/working_copies/merge_tests-105/A_COPY/mu
> 2012-04-27 22:23:27 [INFO] --- Recording mergeinfo for merge of r3
> into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
> 2012-04-27 22:23:27 [INFO] U
> svn-test-work/working_copies/merge_tests-105/A_COPY
> 2012-04-27 22:23:27 [INFO] Summary of conflicts:
> 2012-04-27 22:23:27 [INFO] Skipped paths: 1
>
> The difference is the order of the editor drive. The "good" form sees
> "D mu" first. The "bad form" sees "A MU" first.
>
> I suspect in the bad form, it sees a case-only conflict and decides to
> skip the path. Badness ensues.
>
> I've verified this behavior by manually flipping the order of these
> two changes during the editor drive.
Hi Greg,
Are you seeing this error on a case-sensitive filesystem? When I flip
the ordering I see the above "bad" behavior too (on Windows) but at
first glance it looks like it should work on a case-sensitive
filesystem.
> I don't think there is anything that says we will see deletes first,
> followed by adds. It just "happens" to have done that so far. But my
> recent work ended up changing that order. Boom.
Our of curiosity, which recent work is that?
> Any thoughts on what is going on here? Is there some kind of
> case-conflict check that causes that skip to happen? (or is it
> something else?)
On Windows what happens when the add of 'MU' comes in before the
deletion of 'mu' is that merge.c:merge_file_added performs an
obstruction check, ultimately calling svn_wc__check_for_obstructions:
svn_wc__check_for_obstructions(svn_wc_notify_state_t *obstruction_state,
svn_node_kind_t *kind,
svn_boolean_t *added,
svn_boolean_t *deleted,
svn_wc_context_t *wc_ctx,
const char *local_abspath,
svn_boolean_t no_wcroot_check,
apr_pool_t *scratch_pool)
{
svn_wc__db_status_t status;
svn_kind_t db_kind;
svn_node_kind_t disk_kind;
svn_error_t *err;
*obstruction_state = svn_wc_notify_state_inapplicable;
if (kind)
*kind = svn_node_none;
if (added)
*added = FALSE;
if (deleted)
*deleted = FALSE;
SVN_ERR(svn_io_check_path(local_abspath, &disk_kind, scratch_pool));
^^^^^^
### apr_stat considers 'MU' the same as 'mu',
### so returns disk_kind=svn_node_file...
err = svn_wc__db_read_info(&status, &db_kind, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL,
wc_ctx->db, local_abspath,
scratch_pool, scratch_pool);
^^^^^^
### ...but the DB, being smarter, knows that 'mu' is present, but not 'MU'...
if (err && err->apr_err == SVN_ERR_WC_PATH_NOT_FOUND)
{
svn_error_clear(err);
if (disk_kind != svn_node_none)
{
/* Nothing in the DB, but something on disk */
*obstruction_state = svn_wc_notify_state_obstructed;
^^^^^^
### ...and so we end up here, thinking the addition of 'MU' is
### obstructed (and rightly so on a case-insensitive filesystem)
### so it is skipped.
return SVN_NO_ERROR;
}
> ... and the bigger question: how can you get this to
> work when the changes arrive as MU-first, mu-second?
No simple solution presents itself on a case-insensitive file system,
heck no convoluted solution occurs to me at the moment.
Paul
> Thanks,
> -g
Received on 2012-04-30 16:48:52 CEST