From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.bugs Subject: bug#22032: 24.3; VC doesn't handle hg hidden revisions Date: Tue, 15 Dec 2015 23:53:08 +0000 Message-ID: <868u4vxo9n.fsf@gmail.com> References: <56584054.5080100@gmail.com> <56591524.3010806@yandex.ru> <5659C34E.4070300@gmail.com> <5659EDD4.7030503@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1450223664 21499 80.91.229.3 (15 Dec 2015 23:54:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Dec 2015 23:54:24 +0000 (UTC) To: 22032@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 16 00:54:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a8zQ3-0003Ai-7I for geb-bug-gnu-emacs@m.gmane.org; Wed, 16 Dec 2015 00:54:11 +0100 Original-Received: from localhost ([::1]:39625 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zQ2-0005sH-Ig for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Dec 2015 18:54:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43054) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zPz-0005s8-1p for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:54:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8zPu-0007Ss-1d for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:54:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zPt-0007So-UP for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:54:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1a8zPt-00009t-NZ for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:54:01 -0500 X-Loop: help-debbugs@gnu.org In-Reply-To: <56584054.5080100@gmail.com> Resent-From: Andy Moreton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Dec 2015 23:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22032 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.1450223632593 (code B ref -1); Tue, 15 Dec 2015 23:54:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Dec 2015 23:53:52 +0000 Original-Received: from localhost ([127.0.0.1]:53048 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8zPj-00009U-HZ for submit@debbugs.gnu.org; Tue, 15 Dec 2015 18:53:51 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:32987) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1a8zPh-00009H-ES for submit@debbugs.gnu.org; Tue, 15 Dec 2015 18:53:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8zPa-0007QV-VB for submit@debbugs.gnu.org; Tue, 15 Dec 2015 18:53:44 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:44227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zPa-0007QR-Rm for submit@debbugs.gnu.org; Tue, 15 Dec 2015 18:53:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zPV-0005qX-RG for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:53:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8zPK-0007Ou-9B for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:53:31 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:47993) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8zPJ-0007Ok-UO for bug-gnu-emacs@gnu.org; Tue, 15 Dec 2015 18:53:26 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1a8zPH-00026J-Jp for bug-gnu-emacs@gnu.org; Wed, 16 Dec 2015 00:53:23 +0100 Original-Received: from 82-69-64-228.dsl.in-addr.zen.co.uk ([82.69.64.228]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Dec 2015 00:53:23 +0100 Original-Received: from andrewjmoreton by 82-69-64-228.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 16 Dec 2015 00:53:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 107 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82-69-64-228.dsl.in-addr.zen.co.uk User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) Cancel-Lock: sha1:6uGCh9d0CJL2Z2s/VfFVGQPf6Bs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:110038 Archived-At: On Sat 28 Nov 2015, Dmitry Gutov wrote: > Hi Glenn, > > Please keep the bug address in Cc. I'm reproducing the entirety of your email > here for posterity. > > On 11/28/2015 05:07 PM, Glenn Hutchings wrote: > >> Thanks for the quick response. I've been doing a bit more digging for >> info about this, and think I've figured out exactly how I got into the >> situation. There's an experimental set of features called Changeset >> Evolution that >> modifies the way mercurial rewrites history: instead of stripping a >> changeset, it marks it 'obsolete'. Looks like these features were >> introduced at version 2.9, but by default none of them are used by the >> core mercurial commands. But a recent extension called Evolve >> does use it. If >> you enable that extension, and then perform a "commit --amend", instead >> of updating the head changeset, it creates a new one and makes the >> previous one obsolete (and 'hidden' by default in the change log). >> >> Long story short: the gap in rev numbers only occurs if you enable the >> 'evolve' extension (or another which uses the changeset-evolution >> features) and use a history-modifying command. I recently tried the >> extension out, which is when I came across the bug. > > I see. > >>> Is there a reason why we wouldn't want to use that argument and just >>> always display them? >>> >> >> Well, the hidden revs are really only used internally, and shouldn't be >> seen by users. >> >>> Would calling 'hg diff --hidden' help? >>> >> >> Unfortunately not -- that would only do a diff between the current rev >> and the internal hidden one. Not what the user really wants. > > That makes sense. This problem with revision IDs also accurs if the repo contains named branches. in that case the numerically previous revision may be on a different branch, resulting in a meaningless diff that is slow to compute. For example (from a non-public repo with named branches), where rev 59951 and rev 59950 are on different named branches: $ hg diff -r59951 -r59950 | wc -l 88188 $ hg diff -r59951 -r59951^ | wc -l 70 $ hg id -n -r59951^ 59925 The first example diffs agaist the previous revision ID (which is on a different branch), and produces large and useless diff output. The second example diffs against the (first) parent, and is what is actually wanted. >> I managed to come up with this, using mercurial's 'revset' feature: >> >> hg id --hidden -n -r 'first(X:0 and not hidden())' > > Thanks. Please try this definition and see if it resolves the problem: > > (defun vc-hg-previous-revision (_file rev) > (let ((newrev (1- (string-to-number rev)))) > (when (>= newrev 0) > (with-temp-buffer > (vc-hg-command t 0 nil > "id" "--hidden" "-n" "-r" > (format "first(%d:0 and not hidden())" newrev)) > ;; Trim the trailing newline. > (buffer-substring (point-min) (1- (point-max))))))) > >> This says to look at all non-hidden revs from X down to zero, choose the >> first one, and print its numeric rev number. If the current rev is X+1, >> that gives the first previous non-hidden rev. But I'm sure there must >> be a better way, without having to examine all previous changesets. > > If you anticipated that we'd have to make one process call per revision, then > I think the above definition does better. To also work with named branches, something like this (untested) would be better: (format "last(ancestors(%d) and not hidden())" newrev) >> Given the experimental nature of all this evolution stuff, I'm inclined >> to think that it's not all that urgent a problem to resolve right now. >> But if it ever becomes part of core mercurial, it's something to bear in >> mind. > > Indeed, it seems there's no hurry. On the other hand, I don't expect much harm > from installing the new vc-hg-previous-revision definition either: it works > fine with the version of Mercurial installed on my machine (3.4), although in > all cases I've tried it basically returned the revision passed to it as X. > > If it would cause earlier versions of Mercurial to error out, however, that > would be a reason to hold off on it. Indeed - even after the evolution stuff has matured further, there will still be a large population of machines that are running older versions of Mercurial, and will not understand the "hidden()" predicate. AndyM