From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Giorgos Keramidas Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Thu, 3 Jan 2008 03:08:08 +0200 Message-ID: <20080103010807.GB13318@kobe.laptop> References: <20080101171120.GC3830@muc.de> <20080101.190535.32709273.wl@gnu.org> <20080101182742.GE3830@muc.de> <20080101.192802.05328072.wl@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199322544 26874 80.91.229.12 (3 Jan 2008 01:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jan 2008 01:09:04 +0000 (UTC) Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org, esr@thyrsus.com, acm@muc.de, eliz@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 03 02:09:23 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 1JAEaF-0003YW-UU for ged-emacs-devel@m.gmane.org; Thu, 03 Jan 2008 02:09:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAEZt-0006BR-Nc for ged-emacs-devel@m.gmane.org; Wed, 02 Jan 2008 20:08:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAEZU-000646-Qe for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:08:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAEZS-000630-5Y for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:08:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAEZR-00062v-Me for emacs-devel@gnu.org; Wed, 02 Jan 2008 20:08:29 -0500 Original-Received: from mx-out.forthnet.gr ([193.92.150.104] helo=mx-out-04.forthnet.gr) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JAEZG-0003NU-6b; Wed, 02 Jan 2008 20:08:18 -0500 Original-Received: from mx-av-03.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-04.forthnet.gr (8.13.8/8.13.8) with ESMTP id m0318EiT027725; Thu, 3 Jan 2008 03:08:14 +0200 Original-Received: from MX-IN-02.forthnet.gr (mx-in-02.forthnet.gr [193.92.150.185]) by mx-av-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id m0318EGg019449; Thu, 3 Jan 2008 03:08:14 +0200 Original-Received: from kobe.laptop (ppp5-162.adsl.forthnet.gr [62.1.228.162]) by MX-IN-02.forthnet.gr (8.14.2/8.14.2) with ESMTP id m0318CjH009500; Thu, 3 Jan 2008 03:08:13 +0200 Authentication-Results: MX-IN-02.forthnet.gr smtp.mail=keramida@ceid.upatras.gr; spf=neutral Authentication-Results: MX-IN-02.forthnet.gr header.from=keramida@ceid.upatras.gr; sender-id=neutral Original-Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m0318BRM013669; Thu, 3 Jan 2008 03:08:11 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Original-Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m031899W013668; Thu, 3 Jan 2008 03:08:09 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Content-Disposition: inline In-Reply-To: X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 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:85957 Archived-At: On 2008-01-02 04:53, Richard Stallman wrote: > You can commit a change offline (git commit). Later on, > when you are online, you say `git pull' to get the current > state of the repository, and automatical merging happens > (and the usual warnings if there are conflicts). Finally, > you say `git push' to synchronize your git repository with > the global one. > > Is this substantially different from CVS, or is it just > relabeling? It sounds like `git push' is basically equivalent > to CVS commit. Yes, there is a substantial difference between committing in a distributed SCM like Git, and Mercurial (the latter is the one I am most familiar with). A commit `attaches' a changeset to a `parent changeset', forming a changeset graph instead of a linear history. So if I pull from the central Emacs repository the changes: [1]---[2]---[3] and start committing on top of this, I will end up with a local history like this: [1]---[2]---[3]---[4]---[5]---[6] In the mean time, other people have the chance to commit their own changes to the central tree, on top of the original [3] changeset. When I finish my work, and I `pull' from the central tree again, the local Git history becomes: ,---[7]---[8] / [1]---[2]---[3]---[4]---[5]---[6] A major difference in this sort of history is that *all* changes have been safely stashed away in the local history. The working area of the repository/workspace can, for all intents and purposes, be considered volatile and completely unimporant. Having this sort of local history, I can `check out' any one of the committed changes. Looking at the `remote' changes I just pulled is possible with normal `update' commands in Mercurial (a similar command is available in Git). This means that switching between the `local' version and the `remote' version of the code is as easy as: hg update --clean 8 ; remote version is checked out hg update --clean 6 ; local version is checked out The usual commands, like `diff' also work, i.e.: hg diff -r 6:8 ; look at 6 -> 8 patch hg diff -r 8:6 ; look at the inverse patch Note that a `merge' has not happened yet. If the remote head of the history tree looks easy enough to merge, a merge operation can be done in two ways: 1) Merging of the two heads, to forma history graph like: ,---[7]---[8]---------[9] / / [1]---[2]---[3]---[4]---[5]---[6]--' 2) A `rebase' operation, which restores the linear history of the remote branch, and `rebases' all the local changesets on top of the remote branch: [1]---[2]---[3]---[7]---[8] - - - [4']---[5']---[6'] > With CVS, until you commit your changes, new changes can be > installed in the repository, and when you DO get around to > committing your changes, you will have to merge them with > whatever others have installed. Once you commit, others trying > to commit will have the burden of merging their changes with > your already-committed changes. The main ease of use from the distributed SCM systems is a result of the different from the workflow you just described. With CVS committers are encouraged to avoid committing local changes, until a future moment when ``the patch will be done and fully working''. When they reach that future point, the onus of the merging falls on the person who wants to commit. With a distributed SCM system, committing is not so `scary'. It's ok to commit often, and commit short changes. They are local. They won't break the remote tree for anyone else. Merging can also be done much more often. This means that it's ok to merge or rebase a pile of local changes 10 or 20 times, while they are being developed. If the first sort of merging described above is chosen, then repeated merges work incrementally, so conflicts that have been resolved in one of the past merges don't reappear in future merges. > With git, I would guess that the same situation obtains until > you do `git push' with your changes. Thus, I think that `git > push' is the true analogue to CVS commit. If a dSCM repository is `anointed' by the team as *the* repository, then there are hooks which can control whether: * It is ok to create `remote heads' with unmerged changes (this is what happens for example if someone pushes the sample history graph shown above, before the merge of change [9] happens) * It is ok to push new `branches' in the remote tree > This is based on surmise rather than knowledge. If it is > wrong, where is the mistake? It's mostly right. A `push' operation is that `publishes' a change in a dSCM world. The only difference is that a `commit' in a centralized SCM (like CVS) does several things, which have been split in a more fine-grained set of operations in a distributed SCM system. When a commit happens in CVS then: * A local `merge' has completed * CVS add, or remove commands have been completed * A commit sends the files to the remote server (the `publishing' part) * The local workspace state is updated to match the new state of the tree In a distributed SCM a `commit' is only part of the above: * A changeset is recorded in the local repository storage area * Local workspace state is updated A merge is not strictly necessary, and the changes haven't been published anywhere else yet. HTH, Giorgos