[Bug 5776] New: Disabled path conflict checking for unknown files behavior is different from before the feature was added

mercurial-bugs at mercurial-scm.org mercurial-bugs at mercurial-scm.org
Wed Jan 24 05:15:41 UTC 2018


https://bz.mercurial-scm.org/show_bug.cgi?id=5776

            Bug ID: 5776
           Summary: Disabled path conflict checking for unknown files
                    behavior is different from before the feature was
                    added
           Product: Mercurial
           Version: stable branch
          Hardware: PC
                OS: Windows
            Status: UNCONFIRMED
          Severity: bug
          Priority: normal
         Component: Mercurial
          Assignee: bugzilla at mercurial-scm.org
          Reporter: matt_harbison at yahoo.com
                CC: mbthomas at fb.com, mercurial-devel at mercurial-scm.org,
                    sid+hgbz at less-broken.com

Path conflict checking for merging was introduced in 989e884d1be9, and its
child (7a8a16f8ea22) added the functionality for clearing unknown files.  Then
they were disabled behind an experimental config in 2a774cae3a03.  In theory,
I would have expected this to return to the 989e884d1be9^ behavior.  The
Windows tests say different.[1] (Specifically test-audit-path.t.  I didn't look
to see if the other failure is related.)

Sadly, these messages were either globbed away or missing completely in the
history.

Prior to 989e884d1be9, the error for no-symlink was:

    abort: $TESTTMP\target\back/test: The system cannot find the path
specified.

In 989e884d1be9 (and the same for it's child where unknown was handled), it
became:

    back: is both a file and a directory
    abort: destination manifest contains path conflicts

If the disabled experimental knob is grafted back to 989e884d1be9, the error
is:

   abort: $TESTTMP\target\back/test: The system cannot find the path specified.

And grafted onto the child, the result is a successful update, as has been seen
in recent test failures.  I think the fact that the #if symlink side of things
is actually dealing with a symlink and getting an error, is probably masking
this.

[1]
https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/425/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio

-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Mercurial-devel mailing list