GNU bug report logs - #79024
31.0.50; Multiple working trees support for VC

Previous Next

Full log

Message #196 received at 79024 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: dmitry <at> gutov.dev, 79024 <at> debbugs.gnu.org
Subject: Re: bug#79024: 31.0.50; Multiple working trees support for VC
Date: Sat, 16 Aug 2025 17:03:30 +0300

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: dmitry <at> gutov.dev,  79024 <at> debbugs.gnu.org
> Date: Sat, 16 Aug 2025 14:22:52 +0100
> 
> >   Test vc-test-hg07-other-working-trees condition:
> >       (ert-test-failed
> >        ((should (equal (list second) (vc-call-backend backend ...))) :form
> > 	(equal ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/")
> > 	       nil)
> > 	:value nil :explanation
> > 	(different-types
> > 	 ("c:/Users/EliZ/AppData/Local/Temp/vc-testQIJW1t/second/") nil)))
> >      FAILED  32/56  vc-test-hg07-other-working-trees (0.592570 sec) at lisp/vc/vc-tests/vc-tests.el:1
> >
> > HTH
> 
> It does, thanks.  So, looks like my implementation of the coding systems
> hack for Mercurial is fine.  So I've installed that.
> 
> Then I think what we have is an actual bug instead of just a test suite
> problem.  One or both of vc-hg-add-working-tree and
> vc-hg-known-other-working-trees don't work on Windows.  I suspect that
> it is the latter.
> 
> Could you take a glance over vc-hg-known-other-working-trees and see if
> perhaps it is making obviously invalid assumptions about Windows paths?
> 
> If that doesn't reveal anything, I'd like to ask you to try manually
> creating a new working tree, from Emacs, to rule out any problems with
> vc-hg-add-working-tree.  Something like this:
> 
> - M-x mkdir RET ~/foo RET
> - C-x C-f ~/foo/bar RET blah C-x C-s
> - C-x v v
>   + it should prompt for the backend, choose Hg
> - C-x v v blahblah C-c C-c
>   + checks in the file
> - C-x v w c foo2 RET
> 
> Now check that there is a new tree foo/../foo2/ (or wherever you put it)
> and that the file foo/../foo2/.hg/sharedpath contains the path of the
> original foo.  If there is then we can be pretty sure the problem is
> vc-hg-known-other-working-trees.

Thanks, I hope the problem and its solution are clear from the patch
below.  With that, the test now passes.

I hope using expand-file-name doesn't slow this down too much.  (I
considered using file-equal-p, but the results are undefined if one or
both of the files don't exist.)

diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index e9095b7..564cb00 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1738,7 +1738,10 @@ vc-hg-known-other-working-trees
     (if (file-exists-p our-sp)
         (with-temp-buffer
           (insert-file-contents-literally our-sp)
-          (setq our-store (string-trim (buffer-string)))
+          ;; On MS-Windows, ".hg/sharedpath" gives file names with
+          ;; backslashes; expand-file-name normalizes that to forward
+          ;; slashes, needed for 'equal' comparison below.
+          (setq our-store (expand-file-name (string-trim (buffer-string))))
           (push (abbreviate-file-name (file-name-directory our-store))
                 shares))
       (setq our-store (expand-file-name ".hg" our-root)))
@@ -1748,7 +1751,9 @@ vc-hg-known-other-working-trees
                   ((file-exists-p sp)))
         (with-temp-buffer
           (insert-file-contents-literally sp)
-          (when (equal our-store (buffer-string))
+          (when (equal our-store
+                       ;; See above why we use expand-file-name
+                       (expand-file-name (string-trim (buffer-string))))
             (push root shares)))))
     shares))
 

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.