From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Newsgroups: gmane.emacs.bugs Subject: bug#16254: 24.3.50; bzr error on emacs trunk using vc-print-log Date: Thu, 26 Dec 2013 19:47:07 -0700 Message-ID: References: <87d2kk4zcn.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013d1a94253f3404ee7b1c24 X-Trace: ger.gmane.org 1388112490 3621 80.91.229.3 (27 Dec 2013 02:48:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Dec 2013 02:48:10 +0000 (UTC) To: 16254@debbugs.gnu.org, Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 27 03:48:17 2013 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 1VwNTE-0007xe-5C for geb-bug-gnu-emacs@m.gmane.org; Fri, 27 Dec 2013 03:48:16 +0100 Original-Received: from localhost ([::1]:47696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwNTD-0003Ck-Qk for geb-bug-gnu-emacs@m.gmane.org; Thu, 26 Dec 2013 21:48:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwNT6-0003C1-7E for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2013 21:48:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VwNT1-00079H-3w for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2013 21:48:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VwNT0-00079A-VA for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2013 21:48:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VwNT0-0003Mi-FU for bug-gnu-emacs@gnu.org; Thu, 26 Dec 2013 21:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Christoph Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 27 Dec 2013 02:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16254 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16254-submit@debbugs.gnu.org id=B16254.138811243212850 (code B ref 16254); Fri, 27 Dec 2013 02:48:02 +0000 Original-Received: (at 16254) by debbugs.gnu.org; 27 Dec 2013 02:47:12 +0000 Original-Received: from localhost ([127.0.0.1]:45006 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwNSB-0003L8-Su for submit@debbugs.gnu.org; Thu, 26 Dec 2013 21:47:12 -0500 Original-Received: from mail-lb0-f182.google.com ([209.85.217.182]:53454) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VwNS8-0003Kz-LD for 16254@debbugs.gnu.org; Thu, 26 Dec 2013 21:47:09 -0500 Original-Received: by mail-lb0-f182.google.com with SMTP id l4so3927637lbv.41 for <16254@debbugs.gnu.org>; Thu, 26 Dec 2013 18:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UmKyyxjq6tJxxOpGJAzh6ZMH32ZetwPHycFcNZcEmz4=; b=0v8nMlwF8p4bUBoTEBuiwn7KgiEewXe4LTXUpDzx2tQ3xs+Zd16Pm0LUUiWLfsZUuZ WFKa7/vPE8em3cktpxlG2ISAqwTz49QzUZaNKa8pF5suJDbGxMMPu8zicywE+lm5c3x+ 6ny++GfJaUxDmHZSrf/JL6uPUcI0/AJZ6F/5HhT22zH4F1cPhBmKLj/xbRPUk1ZQ80DN 1FwPDxrSJQo3kGaOW4la2l5UzLZoUVdhbsLhYxwOHp2KA/Ry02jIGGoLjj31y8myQlRo uLH60u2lRb6l749zOu7xc/5blOpToFLuCQ/EiFvX/2OVXoHJOZNh6kCuw6U+SPXXQLaT dyPA== X-Received: by 10.152.6.201 with SMTP id d9mr7566925laa.25.1388112427432; Thu, 26 Dec 2013 18:47:07 -0800 (PST) Original-Received: by 10.152.133.66 with HTTP; Thu, 26 Dec 2013 18:47:07 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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:82640 Archived-At: --089e013d1a94253f3404ee7b1c24 Content-Type: text/plain; charset=ISO-8859-1 This issue seems to be that when deducing the fileset in dired mode, the code does not distinguish between files that are under version control and files that aren't. The following patch adds detection (and filtering) of unregistered members to vc-dired-deduce-fileset. If the marked files have any unregistered files among them, the unregistered files are filtered out. If all files are unregistered, an error is shown. This also covers the main case of selecting just one unregistered file/directory. Thoughts? === modified file 'lisp/vc/vc.el' --- lisp/vc/vc.el 2013-11-26 19:17:55 +0000 +++ lisp/vc/vc.el 2013-12-27 02:40:38 +0000 @@ -1014,10 +1014,19 @@ (t (error "File is not under version control"))))) (defun vc-dired-deduce-fileset () - (let ((backend (vc-responsible-backend default-directory))) - (unless backend (error "Directory not under VC")) - (list backend - (dired-map-over-marks (dired-get-filename nil t) nil)))) + "Deduce a set of files and a backend to which to apply an +operation from all the marked items in a dired buffer. Resulting +fileset only includes items that are version controlled." + (let ((backend (vc-responsible-backend default-directory)) + (fileset + (delq nil (mapcar + (lambda (x) (if (not (equal (vc-backend x) nil)) x)) + (dired-map-over-marks + (dired-get-filename nil t) + nil))))) + (if (not fileset) + (error "Marked fileset is not under version control") + (list backend fileset)))) (defun vc-ensure-vc-buffer () "Make sure that the current buffer visits a version-controlled file." On Wed, Dec 25, 2013 at 11:35 AM, Christoph wrote: > I was wrong. The t argument in vc-deduce-fileset does something > else. Sorry for the noise. > > > > On Wed, Dec 25, 2013 at 11:22 AM, Christoph wrote: > >> vc-print-log was executed from a dired buffer when this happened. >> vc-print-root-log works correctly and prints the Emacs bzr logs. >> >> vc.el has the following code in vc-print-log: >> >> (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t? --Stef >> (backend (car vc-fileset)) >> (files (cadr vc-fileset)) >> ;; (working-revision (or working-revision (vc-working-revision (car >> files)))) >> ) >> (vc-print-log-internal backend files working-revision nil limit))) >> >> The t in vc-decude-fileset allows unregistered files per the >> documentation. To follow Stefan's questions, why would we want unregistered >> files to be included in the fileset for the log command? >> >> I think this should be changed to disallow unregistered files. >> >> Christoph >> >> >> On Wed, Dec 25, 2013 at 10:54 AM, Christoph wrote: >> >>> Some more information on this issue: >>> >>> `vc-print-log` works find in a sub-directory of the tree, e.g. admin. >>> It looks like aclocal.m4 is ignored via .bzrignore and it is the first >>> file in the root tree (after running configure and such). >>> >>> I seem to remember we had a similar problem before that was fixed at >>> some point. >>> >>> >>> On Wed, Dec 25, 2013 at 10:25 AM, Christoph wrote: >>> >>>> >>>> Running `vc-print-log` on a directory containing the Emacs trunk gives >>>> the following error: >>>> >>>> bzr: ERROR: Path unknown at end or start of revision range: aclocal.m4 >>>> >>>> >>>> >>>> In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2) >>>> of 2013-12-14 on marvin >>>> Bzr revision: 115528 tzz@lifelogs.com-20131214195519-pi759t6a59vg9b1i >>>> Windowing system distributor `The X.Org Foundation', version >>>> 11.0.11103000 >>>> System Description: Linux Mint 13 Maya >>>> >>> >>> >> > --089e013d1a94253f3404ee7b1c24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This issue seems to be that when deducing the fileset in d= ired mode, the code does not distinguish between files that are under versi= on control and files that aren't.

The following patc= h adds detection (and filtering) of unregistered members to vc-dired-deduce= -fileset.
If the marked files have any unregistered files among them, the unregi= stered files are filtered out.=A0
If all files are unregistered, = an error is shown. This also covers the main case of selecting just one unr= egistered file/directory.

Thoughts?

=3D=3D=3D modif= ied file 'lisp/vc/vc.el'
--- lisp/vc/vc.el 2013-11-26 19:17:55 +0000
+++= lisp/vc/vc.el 2013-12-27= 02:40:38 +0000
@@ -1014,10 +1014,19 @@
=A0 =A0 =A0 (t (error "File is = not under version control")))))
=A0
=A0(defun vc-d= ired-deduce-fileset ()
- =A0(let ((backend (vc-responsible-backen= d default-directory)))
- =A0 =A0(unless backend (error "Directory not under VC"))
- =A0 =A0(list backend
- =A0 =A0 =A0 =A0 =A0(dired-map-o= ver-marks (dired-get-filename nil t) nil))))
+ =A0"Deduce a = set of files and a backend to which to apply an
+operation from all the marked items in a dired buffer. Resulting
+fileset only includes items that are version controlled."
=
+ =A0(let ((backend (vc-responsible-backend default-directory))
+ =A0 =A0 =A0 =A0(fileset
+ =A0 =A0 =A0 =A0 (delq nil (mapca= r
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(lambda (x) (if (not (= equal (vc-backend x) nil)) x))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0(dired-map-over-marks
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 (dired-get-filename nil t)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 nil)))))
+ =A0 =A0= (if (not fileset)
+ =A0 =A0 =A0 =A0(error "Marked fileset is= not under version control")
+ =A0 =A0 =A0(list backend file= set))))
=A0
=A0(defun vc-ensure-vc-buffer ()
=A0 =A0"Make sure that the current buffer visits a version-contro= lled file."



On Wed, Dec 25, 2013 at 11:35 AM, Chris= toph <cschol2112@gmail.com> wrote:
I was wrong. The t argument= in vc-deduce-fileset does something else.=A0Sorry for the noise.

<= /div>


On Wed,= Dec 25, 2013 at 11:22 AM, Christoph <cschol2112@gmail.com> wrote:
vc-print-log was executed f= rom a dired buffer when this happened. vc-print-root-log works correctly an= d prints the Emacs bzr logs.

vc.el has the following code in vc-print-log:

=A0 (let* ((vc-fileset (vc-deduce-fileset t)) ;FIXME: Why t?= --Stef
(backend (c= ar vc-fileset))
(fi= les (cadr vc-fileset))
;; (working-revision (or = working-revision (vc-working-revision (car files))))
=A0 =A0 =A0 = =A0 =A0)
=A0 =A0 (vc-print-log-internal backend files working-rev= ision nil limit)))

The t in vc-decude-fileset = allows unregistered files per the documentation. To follow Stefan's que= stions, why would we want unregistered files to be included in the fileset = for the log command?

I think thi= s should be changed to disallow unregistered files.

Christoph


On Wed, Dec 25, 2013 at 10:54 AM, Christ= oph <cschol2112@gmail.com> wrote:
Some more information on this issue:=A0

`vc-print-log` works find in a sub-directory of the tree, e.g. admin.
= It looks like aclocal.m4 is ignored via .bzrignore and it is the first file= in the root tree (after running configure and such).

I seem to remember we had a similar problem before that= was fixed at some point.
<= br>
On Wed, Dec 25, 2013 at 10:25 AM, Christo= ph <cschol2112@gmail.com> wrote:

Running `vc-print-log` on a directory containing the Emacs trunk gives
the following error:

bzr: ERROR: Path unknown at end or start of revision range: aclocal.m4



In GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
=A0of 2013-12-14 on marvin
Bzr revision: 115528 tzz@lifelogs.com-20131214195519-pi759t6a59vg9b1i
Windowing system distributor `The X.Org Foundation', version 11.0.11103= 000
System Description: =A0 =A0 Linux Mint 13 Maya




--089e013d1a94253f3404ee7b1c24--