I recently updated scmutil.origpath, so that when ui.origbackuppath is configured, we better handle the cases of path conflicts (file replaced with directories and vice-versa). I missed one of the cases: where the old backup is a symlink to a directory that exists, and the new backup is a file or symlink. This is because vfs.isdir() follows symlinks, so we try to call vfs.rmtree on the symlink, which fails. I have a test and fix coming.
Fixed by https://mercurial-scm.org/repo/hg/rev/ad671b4cb9fc Mark Thomas <mbthomas@fb.com> tests: add a test demonstrating issue5731 If origbackups are in use, a symlink to a valid directory is backed up, and an update is made that attempts to backup a file or link over that symlink, we abort with a bad error message instead of successfully updating. Differential Revision: https://phab.mercurial-scm.org/D1310 (please test the fix)
Fixed by https://mercurial-scm.org/repo/hg/rev/99ab7bc944d2 Mark Thomas <mbthomas@fb.com> scmutil: don't try to delete origbackup symlinks to directories (issue5731) When origbackuppath is set, when looking to see if a file we are backing up conflicts with a directory in the origbackuppath, we incorrectly match on symlinks to directories. This means we try to call vfs.rmtree on the symlink, which fails. Differential Revision: https://phab.mercurial-scm.org/D1311 (please test the fix)
Bug was set to TESTING for 7 days, resolving