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: What a modern collaboration toolkit looks like Date: Sun, 06 Jan 2008 06:11:06 +0900 Message-ID: <877iio0yhh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20080101171120.GC3830@muc.de> <20080101.190535.32709273.wl@gnu.org> <20080101182742.GE3830@muc.de> <20080101.192802.05328072.wl@gnu.org> <20080103010807.GB13318@kobe.laptop> <85wsqqnfce.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199567312 3135 80.91.229.12 (5 Jan 2008 21:08:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 21:08:32 +0000 (UTC) Cc: emacs-devel@gnu.org, esr@thyrsus.com, keramida@ceid.upatras.gr, acm@muc.de, eliz@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 22:08:50 2008 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 1JBGG3-0000Mv-1R for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 22:08:46 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBGFR-00062l-Br for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 16:08:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBGFL-000622-IK for emacs-devel@gnu.org; Sat, 05 Jan 2008 16:07:59 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBGF9-00060V-Dq for emacs-devel@gnu.org; Sat, 05 Jan 2008 16:07:59 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBGF9-00060S-Aj for emacs-devel@gnu.org; Sat, 05 Jan 2008 16:07:47 -0500 Original-Received: from [130.158.97.224] (helo=mtps02.sk.tsukuba.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBGEY-0004fb-HM; Sat, 05 Jan 2008 16:07:12 -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 F18348001; Sun, 6 Jan 2008 06:06:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1DD231A29E5; Sun, 6 Jan 2008 06:11:07 +0900 (JST) In-Reply-To: X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" (+CVS-20071205) XEmacs Lucid X-detected-kernel: by monty-python.gnu.org: 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:86233 Archived-At: Richard Stallman writes: > I think that is a confusing way to compare them. > It focuses on similarities in implementation > rather than on similarities in use and role. Exactly. Let's try the use and role explanation. Usage summary: cvs commit ~ git commit ; git push cvs update ~ git pull Discussion: In CVS, there normally is no local repository, and even if there were one, CVS provides no mechanism for communication between the local repository and the "official" one. So to record your changes as a new version *and* publish your changes, you simply commit: you workspace --- cvs commit --> public repo on server To get others' changes, you pull: you workspace <-- cvs update --- public repo on server In git (and all the others under discussion), to record your changes as a new version, you commit, and then to publish your changes, you push: you you workspace --- git commit --> private repo --- git push --> public repo on laptop on server To get other's changes, you pull: you workspace <-- private repo <-- git pull --- public repo on laptop on server Note that the update of the local workspace is implicit (automatically done by "git pull"). For you personally, frequently disconnected but (I assume) carrying a laptop, that's all you *need* to know, and that's all you'll see of what's happening. The omission of discussion of which branch or trunk etc is deliberate and correct. All VCSes have a notion of the "default branch". All you *need* to know is that the "default branch" of the "official repository is the "trunk", and that the "usual way" of setting up a local clone results in CVS-like behavior, except that to update the trunk, you must first commit locally, then push to the official repository. This separation of commit from push is a huge advantage to those who are often disconnected. I should also mention that some dVCSes *require* that you explicitly select the commits you wish to make. For example, if you want git to behave recursively the way "cvs commit" does, you need to say "git commit -a". However, the analog of "cvs commit file1 file2 ..." is "git commit file1 file2 ...", so I would guess you won't find it hard to acquire the habits. There are many other advantages to these tools, but you can acquire those skills at need. You'll also *want* a deeper understanding of the various operations before making a decision, I'm sure. My purpose here is merely to show how to map your current workflow into the workflow you'd need to use with a dVCS to accomplish the same tasks. Note that others can be doing all the wild-sounding things like "local branching", "pulling from private repos", "cherrypicking", and "rebasing", but you don't need to notice until it suits your purpose. Finally, you probably already know this, but I should caution the reader that words like "commit" and "push" alone do not necessarily have the same meaning as "$VCS commit" and "$VCS push" do. In fact, the various VCSes differ quite a bit in usage, and often end up with a set of commands implementing the same semantics but with the command names permuted! But those are fine points. The basic roles of the commands (at the eagle's eye view given above) remain intuitively similar.