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: New sync'd branch Date: Sat, 29 Aug 2009 12:56:44 +0900 Message-ID: <87y6p3tgqr.fsf@uwakimon.sk.tsukuba.ac.jp> References: <83praic5r5.fsf@gnu.org> <83d46gcnsb.fsf@gnu.org> <87ocq0l2hw.fsf@iki.fi> <83ab1kcmi5.fsf@gnu.org> <877hwom4og.fsf@telefonica.net> <873a7bn9rm.fsf@telefonica.net> <98EAB66C-1F43-4B20-8F41-CAA40BDA58C1@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1251517697 4961 80.91.229.12 (29 Aug 2009 03:48:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Aug 2009 03:48:17 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 29 05:48:10 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 1MhEvA-0006Ig-Lo for ged-emacs-devel@m.gmane.org; Sat, 29 Aug 2009 05:48:09 +0200 Original-Received: from localhost ([127.0.0.1]:38105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhEvA-0000dl-5c for ged-emacs-devel@m.gmane.org; Fri, 28 Aug 2009 23:48:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MhEv4-0000bL-Qc for emacs-devel@gnu.org; Fri, 28 Aug 2009 23:48:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MhEv0-0000Ur-S8 for emacs-devel@gnu.org; Fri, 28 Aug 2009 23:48:02 -0400 Original-Received: from [199.232.76.173] (port=51647 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MhEv0-0000Ui-Jl for emacs-devel@gnu.org; Fri, 28 Aug 2009 23:47:58 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:38151) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MhEuz-00080u-OJ for emacs-devel@gnu.org; Fri, 28 Aug 2009 23:47:58 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id C076F1535A8; Sat, 29 Aug 2009 12:47:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CD6881A2EBB; Sat, 29 Aug 2009 12:56:44 +0900 (JST) In-Reply-To: <98EAB66C-1F43-4B20-8F41-CAA40BDA58C1@gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" 891381effa11+ 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:114815 Archived-At: David Reitter writes: > And I think you'd have to know [a bit about the revision DAG] for > Bzr or Hg, too. Not really. hg is designed to strongly encourage "virtually linear" development, automatically managing the DAG for "small" divergences and using the single command "merge" to manually manage "large" divergences or those with conflicts. By "automatically" I mean that hg dislikes having multiple heads (anonymous branches) in a single workspace, so most users use either the fetch extension or pull -u to pull and merge in a single operation. Thus even though most of the time your local commit will end up being parallel to somebody else's commit in the public repository, almost all the time you're in a state where there's only a single head in your branch. push works to preserve that invariant for the public repository. This keeps merges to a minimum, and you rarely need to be aware of the DAG or even the branch name. The bzr command set is a big mess, intended to support a wide variety of variant workflows with a small number of commands each. Most of the commands are the same across workflows, but often they have wildly varying semantics depending on how your branch is configured. In particular, "commit" can mean "record a version in the local repo" (in a "standalone" branch), "push a version to a remote repo without recording locally" (in a "lightweight checkout") or "record *and* push" (in a "heavyweight checkout" or "bound branch"). bzr is somewhat more friendly to multiple heads than is hg, especially with the loom extension, but the basic philosophy is the same: try to maintain a single-headed DAG as much of the time as possible, and merge only when tactically (the case of a conflict) or strategically (integrating a feature) necessary. You rarely need to be aware of the DAG or the branch name in bzr too, but you do need to be aware of the type of branch (standalone, lightweight checkout, bound branch). In fact, for both hg and bzr, I'd say if you become aware of the DAG you had better be a core VCS hacker. Anybody else is in big trouble, because it requires deep understanding of internals to safely manipulate the DAG directly. git can emulate all of these various workflows to some degree (lightweight checkouts are currently impossible to fully emulate because of restrictions on pushing from "shallow clones"), but you do need to understand the DAG well to do so. Also, in git branching is the cheapest possible operation (a pointer copy) and branch switching is relatively cheap, so branches tend to proliferate. For that reason, you need to be aware of branch names, and it's hard in git to work with anonymous branches.