From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: Another VC terminology change? Date: Fri, 12 Oct 2007 09:47:51 -0700 Message-ID: <200710121647.l9CGlpLY011358@oogie-boogie.ics.uci.edu> References: <20071011143005.GA18057@thyrsus.com> <200710120046.l9C0k3Ti018924@oogie-boogie.ics.uci.edu> <200710121523.l9CFNpOG008776@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1192208478 25093 80.91.229.12 (12 Oct 2007 17:01:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Oct 2007 17:01:18 +0000 (UTC) Cc: esr@thyrsus.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 12 19:01:07 2007 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.50) id 1IgNi4-0002nn-HG for ged-emacs-devel@m.gmane.org; Fri, 12 Oct 2007 18:50:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgNhy-0006RQ-Bt for ged-emacs-devel@m.gmane.org; Fri, 12 Oct 2007 12:49:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IgNhv-0006R5-Tb for emacs-devel@gnu.org; Fri, 12 Oct 2007 12:49:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IgNhv-0006Qd-0x for emacs-devel@gnu.org; Fri, 12 Oct 2007 12:49:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IgNhu-0006QX-TZ for emacs-devel@gnu.org; Fri, 12 Oct 2007 12:49:50 -0400 Original-Received: from oogie-boogie.ics.uci.edu ([128.195.1.41]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IgNhu-0002wb-Nr for emacs-devel@gnu.org; Fri, 12 Oct 2007 12:49:51 -0400 Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by oogie-boogie.ics.uci.edu (8.13.6/8.13.6) with ESMTP id l9CGlpLY011358; Fri, 12 Oct 2007 09:47:51 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri\, 12 Oct 2007 12\:25\:33 -0400") Original-Lines: 37 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-0.763, required 5, autolearn=disabled, ALL_TRUSTED -1.44, J_CHICKENPOX_22 0.60, TW_BZ 0.08) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 9 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:80732 Archived-At: Stefan Monnier writes: > >> >> Not about "checkout" which sometimes means "update" and sometimes "get". > >> > Speaking of "update", vc-update needs to be rethought a bit. > >> > Mercurial, bzr and git (maybe other systems too) don't seem to want to > >> > do merges based on a file, but on changesets. > >> > What should we do about that? > >> > >> Those backends should simply signal an error if requested to update > >> something less than the whole tree. > > > So what would the UI be for that? > > You mean API rather than UI, right? I mean UI. How does the user request a merge on such a VCS? Using "C-x v +" from any VC managed file? Should it then warn that the whole tree is getting merged? > > vc-BACKEND-merge-news currently has a `file' parameter. > > Should backends check if it is a directory, and then run the merge > > command? > > Those backends which can only perform such operations on whole trees, should > (obviously) check that the parameter refers to a whole tree and signal an > error if it doesn't. > > > Who is responsible for updating all the buffers for files that have > > been changed by the merge? > > VC. The backend should return a list of files that were updated (maybe > together with their new status?), and then vc.el will be in charge of > reverting the corresponding buffers (and update the relevant vc-dired > buffers, ...). What happens if there are conflicts in files that are not opened? Should VC show pop a vc-dired window and show them?