GNU bug report logs - #62663
28.2; vc-hg-state returns incorrect results on directories in some repos

Previous Next

To reply to this bug, email your comments to 62663 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; vc-hg-state returns incorrect results on directories in some
 repos
Date: Tue, 04 Apr 2023 10:05:19 -0400

The problem is with vc-hg-state-fast, which parses Mercurial data
structures instead of shelling out to hg.  This is a great idea but our
parsing seems to be wrong right now in some way.

1. Create a new hg repo with:

hg init
  --config format.use_share_safe=false
  --config format.use-persistent-nodemap=false
  --config format.sparse-revlog=false
  --config format.revlog-compression=zlib

(This is disabling some recent hg features which make vc-hg-state use
the slow path.  You can verify that vc-hg-state-fast is going to run by
checking that .hg/requirements is a subset of
vc-hg-supported-requirements)

2. touch foo && hg add foo && hg commit -m.
3. (vc-hg-state-slow ".")
Returns 'up-to-date which is correct (because it shells out to hg)
4. (vc-hg-state ".")
Returns 'unregistered which is wrong

To a user, this manifests as various hg commands failing with errors,
often something like
"vc-find-backend-function: Cannot open load file: No such file or directory, vc-nil"

This also happens on Emacs 29.

(Note that this is independent of my other bug about lack of support for
certain repo requirements.  That bug is about expanding vc-hg-state-fast
support to new repos; this bug is showing that the already existing
support is buggy!)


In GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars)
 of 2023-02-09 built on igm-qws-u12685a
Repository revision: 739b5d0e52d83ec567bd61a5a49ac0e93e0eb469
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: CentOS Linux 7 (Core)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg
 --prefix=/j/office/app/emacs/builds/28.2-20230209-135825'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBXML2
MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Dired by name

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail dabbrev pp cl-print log-edit
message rmc puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util rmail rmail-loaddefs auth-source eieio eieio-core cl-macs
eieio-loaddefs password-cache json map time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log shell pcomplete comint ansi-color ring misearch
multi-isearch jka-compr find-func shortdoc text-property-search
vc-annotate vc-filewise thingatpt help-fns radix-tree help-mode cl-seq
vc-mtn vc-hg vc-git diff-mode easy-mmode vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs vc-dir seq byte-opt gv bytecomp byte-compile cconv ewoc vc
vc-dispatcher dired-aux cl-loaddefs cl-lib dired dired-loaddefs
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 119456 11097)
 (symbols 48 13754 1)
 (strings 32 40872 1164)
 (string-bytes 1 1248921)
 (vectors 16 18713)
 (vector-slots 8 234707 16776)
 (floats 8 86 32)
 (intervals 56 1922 0)
 (buffers 992 25)
 (heap 1024 18673 1560))

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, 62663 <at> debbugs.gnu.org,
 Daniel Colascione <dancol <at> dancol.org>
Subject: Re: bug#62663: 28.2; vc-hg-state returns incorrect results on
 directories in some repos
Date: Thu, 13 Apr 2023 03:44:30 +0300

Hi! Thanks for the report.

On 04/04/2023 17:05, Spencer Baugh wrote:
> The problem is with vc-hg-state-fast, which parses Mercurial data
> structures instead of shelling out to hg.  This is a great idea but our
> parsing seems to be wrong right now in some way.
> 
> 1. Create a new hg repo with:
> 
> hg init
>    --config format.use_share_safe=false
>    --config format.use-persistent-nodemap=false
>    --config format.sparse-revlog=false
>    --config format.revlog-compression=zlib
> 
> (This is disabling some recent hg features which make vc-hg-state use
> the slow path.  You can verify that vc-hg-state-fast is going to run by
> checking that .hg/requirements is a subset of
> vc-hg-supported-requirements)
> 
> 2. touch foo && hg add foo && hg commit -m.
> 3. (vc-hg-state-slow ".")
> Returns 'up-to-date which is correct (because it shells out to hg)
> 4. (vc-hg-state ".")
> Returns 'unregistered which is wrong
> 
> To a user, this manifests as various hg commands failing with errors,
> often something like
> "vc-find-backend-function: Cannot open load file: No such file or directory, vc-nil"
> 
> This also happens on Emacs 29.
> 
> (Note that this is independent of my other bug about lack of support for
> certain repo requirements.  That bug is about expanding vc-hg-state-fast
> support to new repos; this bug is showing that the already existing
> support is buggy!)

Patches are welcome, of course.

I'm going to Cc the original author of that code, but that's just for 
courtesy.

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 62663 <at> debbugs.gnu.org, control <at> debbugs.gnu.org
Subject: Re: bug#62663: 28.2; vc-hg-state returns incorrect results on
 directories in some repos
Date: Tue, 04 Mar 2025 12:11:23 +0800

tag 62663 - confirmed + moreinfo
thanks

Hello,

On Tue 04 Apr 2023 at 10:05am -04, Spencer Baugh wrote:

> The problem is with vc-hg-state-fast, which parses Mercurial data
> structures instead of shelling out to hg.  This is a great idea but our
> parsing seems to be wrong right now in some way.
>
> 1. Create a new hg repo with:
>
> hg init
>   --config format.use_share_safe=false
>   --config format.use-persistent-nodemap=false
>   --config format.sparse-revlog=false
>   --config format.revlog-compression=zlib
>
> (This is disabling some recent hg features which make vc-hg-state use
> the slow path.  You can verify that vc-hg-state-fast is going to run by
> checking that .hg/requirements is a subset of
> vc-hg-supported-requirements)

ITYM .hg/requires, right?  When I create a repository in this way, that
file contains share-safe, whether or not I pass those --config options.
I've hg 6.3.2 here.

> 2. touch foo && hg add foo && hg commit -m.
> 3. (vc-hg-state-slow ".")
> Returns 'up-to-date which is correct (because it shells out to hg)
> 4. (vc-hg-state ".")
> Returns 'unregistered which is wrong

This recipe doesn't work for me.  Evaluating both of these forms yields
nil.  Evaluating them with "foo" instead of "." yields up-to-date in
both cases.

Is it possible that this problem is only reproducible with newer hg?

Could you confirm your recipe still works, and let me know the version
of hg, please?

Thanks.

-- 
Sean Whitton

Previous Next

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