[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merge 105, issue 3115: case-only rename merges

From: Paul Burba <ptburba_at_gmail.com>
Date: Mon, 30 Apr 2012 10:48:19 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.