From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: vc-dir and Bazaar Date: Sat, 24 Jul 2010 19:52:44 +0300 Message-ID: <83r5is9603.fsf@gnu.org> References: <87r5iube2m.fsf@escher.home> <87r5itzxy7.fsf@telefonica.net> <87tynpkh3k.fsf@escher.home> <83y6d18goj.fsf@gnu.org> <8739v9ytx3.fsf@escher.home> <83tynp83z6.fsf@gnu.org> <87vd84yhql.fsf@escher.home> NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1279990852 11770 80.91.229.12 (24 Jul 2010 17:00:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 24 Jul 2010 17:00:52 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jul 24 19:00:51 2010 Return-path: Envelope-to: geh-help-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 1Oci5P-0005oj-Hp for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Jul 2010 19:00:32 +0200 Original-Received: from localhost ([127.0.0.1]:38615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oci5O-0001RU-Lu for geh-help-gnu-emacs@m.gmane.org; Sat, 24 Jul 2010 13:00:30 -0400 Original-Received: from [140.186.70.92] (port=37778 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oci4n-0001Q1-3l for help-gnu-emacs@gnu.org; Sat, 24 Jul 2010 12:59:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oci4k-0001VQ-Tj for help-gnu-emacs@gnu.org; Sat, 24 Jul 2010 12:59:51 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51190) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oci4k-0001VF-Kz for help-gnu-emacs@gnu.org; Sat, 24 Jul 2010 12:59:50 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L6200I00MUBAK00@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Sat, 24 Jul 2010 19:52:45 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.61.30]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L6200IQ9MVW3X00@a-mtaout20.012.net.il> for help-gnu-emacs@gnu.org; Sat, 24 Jul 2010 19:52:45 +0300 (IDT) In-reply-to: <87vd84yhql.fsf@escher.home> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:74277 Archived-At: > From: Stephen Berman > Date: Sat, 24 Jul 2010 18:20:02 +0200 > > Why "merge-news" instead of simply "merge"? Is there a difference? The "merge-news" method merges recent changes from the current branch. That is different from "merge". You can see the list of all methods in the commentary at the beginning of vc.el. That said, I agree that the message is confusingly technical, especially since these methods are not documented in the manual. Perhaps submit a bug report for that. > > Yes, but more importantly, you can commit _all_ of the pending merges > > if you just don't mark any files. That's what you should do most of > > the time anyway, this being a changeset-based VCS, right? > > Ah, thanks, I somehow overlooked this in the doc string. That did what > I wanted; but after it executed, I got this message: > "vc-do-command: Running bzr status admin/nt/makedist.bat...FAILED > (status 3)" and the *vc-dir* buffer showed all the files as uncommitted > that it displayed before I had type `v'. But when I refreshed the > buffer, it showed only the directories. And when I tried to commit the > merged files from the command line, it said there were no changes to > commit. So `v' worked in vc-dir despite the error message and the > non-updated display. The error message was for "bzr status", not for "bzr ci". So the failed command was not the one which committed the merged files, it was the "bzr status" command run afterwards to show the results in the *vc-dir* buffer. The error message usually means that some other bzr command was running when "bzr status" was invoked. You should be able to see what commands where run at what times in your ~/.bzr.log file. > Should I report a bug about that? Yes, I think so.