From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Scholtes Newsgroups: gmane.emacs.bugs Subject: bug#8025: 24.0.50; vc-bzr does not perform initial commit Date: Tue, 01 Mar 2011 09:19:47 -0700 Message-ID: <4D6D1CA3.4050307__43135.471121832$1298997419$gmane$org@gmail.com> References: <86hbc9yscs.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1298997419 2358 80.91.229.12 (1 Mar 2011 16:36:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 1 Mar 2011 16:36:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: 8025@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 01 17:36:55 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PuSZC-0004lc-V8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Mar 2011 17:36:55 +0100 Original-Received: from localhost ([127.0.0.1]:51618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuSZC-0007Cx-F1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 01 Mar 2011 11:36:54 -0500 Original-Received: from [140.186.70.92] (port=38995 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuSZ7-0007Cp-A6 for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:36:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuSZ5-0002dv-S0 for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:36:49 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37931) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuSZ5-0002dm-Nk for bug-gnu-emacs@gnu.org; Tue, 01 Mar 2011 11:36:47 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PuSKn-0004MN-QK; Tue, 01 Mar 2011 11:22:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Christoph Scholtes Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Mar 2011 16:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 8025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 8025-submit@debbugs.gnu.org id=B8025.129899650316730 (code B ref 8025); Tue, 01 Mar 2011 16:22:01 +0000 Original-Received: (at 8025) by debbugs.gnu.org; 1 Mar 2011 16:21:43 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuSKU-0004Ln-Pi for submit@debbugs.gnu.org; Tue, 01 Mar 2011 11:21:43 -0500 Original-Received: from mail-vx0-f172.google.com ([209.85.220.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PuSKT-0004Lb-8t for 8025@debbugs.gnu.org; Tue, 01 Mar 2011 11:21:41 -0500 Original-Received: by vxg33 with SMTP id 33so3951110vxg.3 for <8025@debbugs.gnu.org>; Tue, 01 Mar 2011 08:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6xMuULX/kKnGyLiJ/p7iagx/X1GFiRfoUKH1RlTCDt8=; b=W6JgAa+miwYKhiXPKZByvHhXxgmK2CGg9e/mP9+/xDXyI57qSZC3TJk76KMmG1ryfq +DaZat0XNTZKnk9FpG4b6BQnsD3Xmw96XzaH0mmQYxlOJTx7Vsj+YkxbA/7jHesmcKDj 5yRLcYm8DiBILWSCyGHQuYRMIDpeiBwy/A0Fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tRnlza3F3OFjvf8ptUAdtIURNHNg1EZ9BEG0GmPtySm8mUaXcgHc0kokTbiZtHY5te XXzF+hNw4hbbyGouhcddgIzDWWjHPqj6ncDie0WaUmWBeOYJoOzPozKr1NHbP9XSJ+LE Q68J7ZbEd1rhLfIPgFSy1MUwIqqP6LnPOiFqw= Original-Received: by 10.52.164.3 with SMTP id ym3mr11481663vdb.127.1298996398942; Tue, 01 Mar 2011 08:19:58 -0800 (PST) Original-Received: from [192.168.1.5] (71-208-180-213.hlrn.qwest.net [71.208.180.213]) by mx.google.com with ESMTPS id cq4sm933155vdb.37.2011.03.01.08.19.51 (version=SSLv3 cipher=OTHER); Tue, 01 Mar 2011 08:19:56 -0800 (PST) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 In-Reply-To: <86hbc9yscs.fsf@gmail.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Tue, 01 Mar 2011 11:22:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:44476 Archived-At: I looked into this issue yesterday and I narrowed it down to the following function in `vc-bzr.el': `vc-bzr-state-heuristic'. Apparently, when there is a bare repo and when trying to register the first file, the heuristic function, which parses the dir-state file, fails and reports the file unregistered all the time, even after it has been registered. It starts working correctly when you register the file and commit the file externally. I have not been able to figure out why the parsing fails. It also works when bypassing the heuristic function and calling `vc-bzr-state' all the time. I am wondering whether the heuristic function should be removed/simplified. There is a comment at the beginning of the function: ;; `bzr status' was excruciatingly slow with large histories and ;; pending merges, so try to avoid using it until they fix their ;; performance problems. ;; This function tries first to parse Bzr internal file ;; `checkout/dirstate', but it may fail if Bzr internal file format ;; has changed. As a safeguard, the `checkout/dirstate' file is ;; only parsed if it contains the string `#bazaar dirstate flat ;; format 3' in the first line. `excruciatingly slow' does not mean anything to me. Is this still an issue with the latest version of bzr? If we can be reasonably sure it is not, we should just have it call `vc-bzr-state' all the time and eliminate this fragile construct of parsing the file manually. I think if bzr has a performance issue bzr should be fixed not emacs. So, my question is: do I spent the time trying to fix this issue or can we agree to make bzr work like any of the other backends and call its native stat function all the time? Also, does anybody have actual performance numbers that would support keeping this function around? Christoph