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: Strange message from "bzr pull" Date: Thu, 31 Dec 2009 18:39:43 +0900 Message-ID: <87r5qbo528.fsf@uwakimon.sk.tsukuba.ac.jp> References: <877hs5ogv8.fsf@red-bean.com> <83my11ejmr.fsf@gnu.org> <83ljgleiir.fsf@gnu.org> <87y6klo9zz.fsf@telefonica.net> <87637plftj.fsf@red-bean.com> <87iqbpo8bp.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1262251787 17178 80.91.229.12 (31 Dec 2009 09:29:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Dec 2009 09:29:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 31 10:29:40 2009 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 1NQHLe-0003T9-A6 for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 10:29:38 +0100 Original-Received: from localhost ([127.0.0.1]:36982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQHLe-0006sA-MX for ged-emacs-devel@m.gmane.org; Thu, 31 Dec 2009 04:29:38 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQHLY-0006qs-O3 for emacs-devel@gnu.org; Thu, 31 Dec 2009 04:29:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQHLT-0006pY-D4 for emacs-devel@gnu.org; Thu, 31 Dec 2009 04:29:31 -0500 Original-Received: from [199.232.76.173] (port=56037 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQHLT-0006pV-8s for emacs-devel@gnu.org; Thu, 31 Dec 2009 04:29:27 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:41411) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQHLS-00005V-NW for emacs-devel@gnu.org; Thu, 31 Dec 2009 04:29:27 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id E304F820D; Thu, 31 Dec 2009 18:29:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5EA161A33D7; Thu, 31 Dec 2009 18:39:43 +0900 (JST) In-Reply-To: <87iqbpo8bp.fsf@telefonica.net> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 1444e28f1a3d XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:119127 Archived-At: =D3scar Fuentes writes: > Karl Fogel writes: >=20 > >>BzrForEmacsDevs is not simple enough for people who have CVS > >>incorporated into their DNA. IMHO it lacks some clear explanation of > >>the new concepts (revisions, branches, merges, histories, divergence, > >>etc) > > > > Several places in the document (including the The Other Resources > > section) already point to > > http://wiki.bazaar.canonical.com/BzrForCVSUsers, which has the material > > you describe. >=20 > That document is too shallow, barely qualifies as an introduction. http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html may contain some useful information. It assumes substantial familiarity with git, so the very basic stuff is not given there. > It doesn't hint at what a revision, for instance. Nobody that reads > that document knows that the key information that makes DVCS > possible is what you see with >=20 > bzr log --show-ids I agree that the concept that a revision has a universally unique ID needs to be mentioned, and that a branch knows which IDs it contains, and can therefore reproduce by updating a working tree. But the sentence I just wrote is horrible, nobody who doesn't already understand will learn anything from it :-), and I don't think a reference to "--show-ids" will help much. You need to explain what those IDs mean. Specifically, they represented directed arcs in a graph. I think that for Emacs developers it may be useful to think of a "commit" or "revision" by analogy to the Lisp cons. The "car" contains a pointer to the revision metadata and the actual content (files). The "cdr" is the parent revision. The obvious part of the generalization is that the "cdr" may be multiple-valued in the case of a merge commit, which has multiple parents. To continue the analogy, a branch is like a Lisp list, with the root commit being the final "cons" which has "cdr" of "nil" (ie, it has no parent). The less obvious part of the generalization is that in a DVCS the pointer(s) in the "cdr" (and in the "car") are *universal*. In the Emacs Lisp implementation those are machine addresses, and they are implementation details that are only exposed in the debugger. But in DVCS, that cannot be so: the communication protocol between different branches (even on the same host!) needs to use them. *Every* bzr branch either assigns the same universal meaning to the id, or it knows that that id is not part of the branch. It's true that the information about revision IDs and content IDs locally may not be of great interest at the moment. However, they will automatically be universally valid if you ever push from your branch, or somebody pulls from it. It is the universality that makes *distributed* VCS possible. N.B. With respect to git, this description is a pretty accurate description of the implementation. For Mercurial and Bazaar, the implementations are substantially different to support various features of each DVCS, but all of them do have a concept of the "history DAG", which is represented by links among "revision objects".