From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: vc-update for bzr etc. Date: Tue, 23 Nov 2010 14:29:37 -0500 Message-ID: <87d3pvalem.fsf@stupidchicken.com> References: <87y68m7kdh.fsf@stupidchicken.com> <87lj4mk2e5.fsf@stupidchicken.com> <87mxp2bd12.fsf@stupidchicken.com> <87tyjauga0.fsf@stupidchicken.com> <87eiacg6lj.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1290542618 13110 80.91.229.12 (23 Nov 2010 20:03:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 23 Nov 2010 20:03:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 23 21:03:34 2010 Return-path: Envelope-to: ged-emacs-devel@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 1PKz3B-000160-57 for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 21:03:34 +0100 Original-Received: from localhost ([127.0.0.1]:48096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKz34-00012q-J1 for ged-emacs-devel@m.gmane.org; Tue, 23 Nov 2010 15:01:06 -0500 Original-Received: from [140.186.70.92] (port=41578 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKyZR-000500-RT for emacs-devel@gnu.org; Tue, 23 Nov 2010 14:31:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKyYd-0004KS-93 for emacs-devel@gnu.org; Tue, 23 Nov 2010 14:30:28 -0500 Original-Received: from pantheon-po16.its.yale.edu ([130.132.50.72]:50763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKyYd-0004KB-7H; Tue, 23 Nov 2010 14:29:39 -0500 Original-Received: from furball (dhcp128036226124.central.yale.edu [128.36.226.124]) (authenticated bits=0) by pantheon-po16.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id oANJTcWr031609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Nov 2010 14:29:38 -0500 Original-Received: by furball (Postfix, from userid 1000) id B4B4C160AC8; Tue, 23 Nov 2010 14:29:37 -0500 (EST) In-Reply-To: (Dan Nicolaescu's message of "Tue, 23 Nov 2010 12:02:08 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133076 Archived-At: Dan Nicolaescu writes: > I have an implementation of `pull' that also takes a `revision' argument. > And in the *vc-incoming* buffer there's a binding for vc-pull to pull > up to the revision at point (use pull --revision=ARG). Good. >> Also, do I need to do anything special to update VC-dir buffers after >> merging or pulling? > > Not only VC-dir buffers, but all buffers containing files in the > target directory. See for example the vc-resynch-buffer in the > vc-retrieve-tag (which could use a better name). OK, I've got some code working that makes vc-bzr-merge/update call or refresh VC-dir after finishing, e.g. it shows "updated" files after a bzr update. But the interface feels flimsy, somehow. The VC-dir buffer displays no indication while the merge/pull is running. Afterwards, there is no sign that the operation has completed, other than an echo area message (easily overwritten by other Emacs commands) and some changes in file status (easily overlooked). For example, if you do an update operation that completes without doing anything, it's easy to miss when the update finishes. In contrast, when the VCS messages are put into a compilation-like buffer, it's always clear what has taken place. So it seems like there needs to be some kind of status message display in the VC-dir buffer, showing (at least) the most recent VCS operation and its status. WDYT?