From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#24082: [PATCH] Use =?UTF-8?Q?=E2=80=98cvs_?= =?UTF-8?Q?update=E2=80=99?= instead =?UTF-8?Q?=E2=80=98cvs_?= =?UTF-8?Q?status=E2=80=99?= for CVS *vc-dir* buffers Date: Sat, 8 Oct 2016 04:01:22 +0300 Message-ID: <4af6dea0-e5e9-6bc7-c10f-a792f16874a5@yandex.ru> References: <87y420arg5.fsf@xi.bootis> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1475888551 18764 195.159.176.226 (8 Oct 2016 01:02:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 8 Oct 2016 01:02:31 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Thunderbird/49.0 Cc: 24082@debbugs.gnu.org To: =?UTF-8?Q?G=C3=B6ktu=C4=9F?= Kayaalp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Oct 08 03:02:27 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsg1p-0003Qs-Ul for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Oct 2016 03:02:18 +0200 Original-Received: from localhost ([::1]:38848 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsg1o-0008IR-Ik for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Oct 2016 21:02:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35608) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsg1e-0008II-5t for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 21:02:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bsg1a-0007Kj-02 for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 21:02:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bsg1Z-0007KW-TO for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 21:02:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bsg1Z-0004jO-J6 for bug-gnu-emacs@gnu.org; Fri, 07 Oct 2016 21:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Oct 2016 01:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24082 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 24082-submit@debbugs.gnu.org id=B24082.147588849118149 (code B ref 24082); Sat, 08 Oct 2016 01:02:01 +0000 Original-Received: (at 24082) by debbugs.gnu.org; 8 Oct 2016 01:01:31 +0000 Original-Received: from localhost ([127.0.0.1]:48146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsg15-0004if-Ho for submit@debbugs.gnu.org; Fri, 07 Oct 2016 21:01:31 -0400 Original-Received: from mail-wm0-f52.google.com ([74.125.82.52]:34774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bsg14-0004iS-Av for 24082@debbugs.gnu.org; Fri, 07 Oct 2016 21:01:30 -0400 Original-Received: by mail-wm0-f52.google.com with SMTP id i130so7384018wmg.1 for <24082@debbugs.gnu.org>; Fri, 07 Oct 2016 18:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=xtn+wVKCbQp18fnaRWyGJgAVlTsqupSPSX6IsDdJgWU=; b=jnjkVtOZ+wABXw2I37xiCwz6ybsNMRk1DUJdIsiJd9agop49K7vKRwYxX4/t8EgvXO MGzfP+L8FfG5Ncfl0A0N9Hn7z8sBcnbknl9hEruFmjXKjZ2H5ZUH5iWaB0Gn37rUGXhl SpWRdoGRHnwgxLBTnKWPRC25YH9OAaDAdQ4PCqwRoKJnRLfO7+J5ZgWqFE8z8QGsg9RB TRT4+Ammdh4qGhweKf3r8dsyITiV+/y+LJHcNnM0RilFBSTMAp8ZuYZ8d+lY/IXKa5Z+ nCKPwmEdtQ04OzVVYj0Bzv+FZIfkp2WsYLE6VVfbPatUIoNd3jiPpKEV/Ef+DEyZ2ZHO 6+rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=xtn+wVKCbQp18fnaRWyGJgAVlTsqupSPSX6IsDdJgWU=; b=Bp5Kp9PjOfe0COQB/owto889yhe7GTS09t9Fs/lhFYOlixAV0iD5a0JRKdyc1wAGcy MmDZeYvnbDjSDkHFkPnfkyt03Tdbetba//xnFASwyKBhlYnrzDaoEoaQpqt2ixEaV98y p1Nu6YjL8U3zdYs0uyauZOZoc7OlW4rXvHwmSmn4gNHa0xq8C32THtRmiSZgcZ3sS2H1 xP+jFY23wjmp4aySarUh89ZZKrWcL0d2MQAFtwpIsRr5gMh1kKpcwLjzsr71Z32l13gy ZK5Cv+hRC1Z8lFb90mP3tt/Ob5qRkCM4SFsyo7PxCNNnz8GfWoO6f8q2kHi1lHFaoO6B H2tw== X-Gm-Message-State: AA6/9Rma7/qediKB2EbSj9QVk6RZWvd/c832Uc59g/7hJWUSLkP0tId/w+hlu1VFnRc1Gw== X-Received: by 10.194.11.100 with SMTP id p4mr18115523wjb.125.1475888484475; Fri, 07 Oct 2016 18:01:24 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.103]) by smtp.googlemail.com with ESMTPSA id 17sm22059197wju.44.2016.10.07.18.01.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Oct 2016 18:01:23 -0700 (PDT) In-Reply-To: <87y420arg5.fsf@xi.bootis> 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" Xref: news.gmane.org gmane.emacs.bugs:124183 Archived-At: On 07.10.2016 22:29, Göktuğ Kayaalp wrote: > On 2016-10-07 02:25:24 AM +0300, Dmitry Gutov wrote: >> Hi! Sorry for the long wait. > > No problem, though actually I'm the one who caused the long delay b/c I > was too late to send in copyright papers, sorry :) We could have done the review earlier. But anyway... > On a computer with CVS installed, these commands should create a working > directory with which the bug can be reproduced: Thank you, that works. > The output for the ‘cvs status’ command does not provide adequate > information to reliably and simply construct the full path to each > file. The output from the abovementioned command in the checkout the > commands I listed created is like follows: > > ,---- > | cvs status: Examining . > | =================================================================== > | File: testfil Status: Locally Modified > | > | Working revision: 1.1.1.1 Fri Oct 7 18:46:53 2016 > | Repository revision: 1.1.1.1 /tmp/cvsroot/test/testfil,v > | Sticky Tag: (none) > | Sticky Date: (none) > | Sticky Options: (none) > | > | cvs status: Examining subdir > | =================================================================== > | File: subfil Status: Locally Modified > | > | Working revision: 1.1.1.1 Fri Oct 7 18:46:53 2016 > | Repository revision: 1.1.1.1 /tmp/cvsroot/test/subdir/subfil,v > | Sticky Tag: (none) > | Sticky Date: (none) > | Sticky Options: (none) > `---- > > The code was trying to rememeber the ‘cvs status: Examining ’ > line in order to reconstruct the path, a method that's fragile and > which requires a lot of regexp magic. Maybe the problem here is that the output we have to deal with does not contain "Examining subdir" because the current implementation of vc-cvs-dir-status-files passes each individual files name to 'cvs -f status'. And 'cvs -f status testfil subdir/subfil' does not output that line. I think the most reasonable approach for that solution would be to parse the "Repository revision" lines. Apparently, vc-cvs-dir-status-files was always broken for this usage, and the problem has surfaced now when we've reimplemented dir-status on top of dir-status-files. ‘cvs update’, instead has a very > filter-friendly and determinable output syntax also imitated by other > version control software (output for the same checkout): That looks reasonable. However, it looks like a significant change, so I'm not sure it's appropriate for Emacs 25.2. We'd like to get *a* fix into 25.2, however. > I actually sort-a-kind-a fixed the ‘cvs status’ version initially, but > it's waay slower than using update. I don't have that fix anymore, but > as I said, using ‘cvs update’ is more robust, simpler, and faster. In > order to fix the ‘cvs status’ method, I read the relevant files from the > CVS/ subdir of the checkout, reconstruct the absolute module path using > info from files therewithin, than subtract that from the third column of > the ‘ Repository version:...’ lines for each file to find its relative > path to the checkout's root directory, ending up with a complex and > fragile hack, that's also slow and incomplete. Couldn't you subtract those values from default-directory instead? > Well, I'm unaware of both the history of the command and why the related > Elisp was commented out, though I do not think that the output format > changed in a long time, or that anything else really changed in CVS > recently :) I recommend asking someone more knowledgeable than me OK, let's ask Dan. In the meantime, here's a simple fix we can consider. This would still adhere to the dir-status-files protocol, but it's probably slower than ideal: diff --git a/lisp/vc/vc-cvs.el b/lisp/vc/vc-cvs.el index a2499a2..e949f30 100644 --- a/lisp/vc/vc-cvs.el +++ b/lisp/vc/vc-cvs.el @@ -1073,7 +1073,7 @@ vc-cvs-dir-status-files (if (and (not files) local (not (eq local 'only-file))) (vc-cvs-dir-status-heuristic dir update-function) (if (not files) (setq files (vc-expand-dirs (list dir) 'CVS))) - (vc-cvs-command (current-buffer) 'async files "-f" "status") + (vc-cvs-command (current-buffer) 'async dir "-f" "status") ;; Alternative implementation: use the "update" command instead of ;; the "status" command. ;; (vc-cvs-command (current-buffer) 'async