From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: vc-update for bzr etc. Date: Mon, 22 Nov 2010 20:04:01 +0900 Message-ID: <87d3pxd3ha.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87y68m7kdh.fsf@stupidchicken.com> <87lj4mk2e5.fsf@stupidchicken.com> <87mxp2bd12.fsf@stupidchicken.com> <87k4k6c738.fsf@uwakimon.sk.tsukuba.ac.jp> <871v6dpx8z.fsf@ambire.localdomain> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1290423826 25253 80.91.229.12 (22 Nov 2010 11:03:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Nov 2010 11:03:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: Thien-Thi Nguyen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 22 12:03:42 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 1PKUBQ-0006Pi-Jx for ged-emacs-devel@m.gmane.org; Mon, 22 Nov 2010 12:03:40 +0100 Original-Received: from localhost ([127.0.0.1]:44928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKUBP-0002fr-IS for ged-emacs-devel@m.gmane.org; Mon, 22 Nov 2010 06:03:40 -0500 Original-Received: from [140.186.70.92] (port=42053 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PKUB8-0002en-19 for emacs-devel@gnu.org; Mon, 22 Nov 2010 06:03:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PKUB6-00054o-JL for emacs-devel@gnu.org; Mon, 22 Nov 2010 06:03:21 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:60951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PKUB6-00054Q-1V for emacs-devel@gnu.org; Mon, 22 Nov 2010 06:03:20 -0500 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C53E82AF543; Mon, 22 Nov 2010 20:03:16 +0900 (JST) Original-Received: from mgmt1.sk.tsukuba.ac.jp (unknown [130.158.97.223]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id B46AB2AF542; Mon, 22 Nov 2010 20:03:16 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id AF5273FA0547; Mon, 22 Nov 2010 20:03:16 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4E6381A3FC7; Mon, 22 Nov 2010 20:04:01 +0900 (JST) In-Reply-To: <871v6dpx8z.fsf@ambire.localdomain> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:132997 Archived-At: Thien-Thi Nguyen writes: > () "Stephen J. Turnbull" > () Mon, 22 Nov 2010 13:31:23 +0900 > > bzr pull -- synchronize branch to parent exactly, never does a > non-trivial merge, sometimes operates on a non-local > branch and not on the workspace IIRC. > git pull -- merges branch into workspace, commits unless conflict, > never affects a branch outside of the workspace. > hg pull -- fetches branch, never updates workspace or affects a > branch outside of the workspace. > > I don't see the point of having a single command whose implementation > can vary so randomly. That's not a uniform UI, that's a > nondeterministic one. > > I agree that perfectly uniform semantics is not really possible, of > course. > > Looks like the sub-operations are: > > (0) determine "news" > (1) download "news" (to some temporary space) > (2) merge (conditionally, looping for conflict resolution, etc) > (3) commit > > Can these DVCSes do such sub-operations *individually* somehow? > Step (3) is given, but the others? I believe so, although the solutions in the case of bzr might be exceptionally gross and possibly inefficient (eg, to do (1) I think you would have to either create a new branch, or get the revid of the tip and then uncommit, which doesn't destroy any commits, it just rewinds the tip in the same way that git reset does). git's solution to (0) is a bit ugly too ("fetch --dry-run"), while bzr provides "missing" and hg "incoming".