From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?=D3scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Sat, 05 Jan 2008 07:59:07 +0100 Message-ID: References: <20071230122217.3CA84830B9A@snark.thyrsus.com> <20071231130712.GB8641@thyrsus.com> <87y7b96az8.fsf@member.fsf.org> <87fxxfnrhi.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1199516372 28321 80.91.229.12 (5 Jan 2008 06:59:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 06:59:32 +0000 (UTC) Cc: Richard Stallman To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 07:59:53 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 1JB30b-00011C-F7 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 07:59:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB30F-0006mC-4d for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 01:59:31 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JB306-0006jg-Oj for emacs-devel@gnu.org; Sat, 05 Jan 2008 01:59:22 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JB305-0006jA-RG for emacs-devel@gnu.org; Sat, 05 Jan 2008 01:59:22 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JB305-0006j3-LD for emacs-devel@gnu.org; Sat, 05 Jan 2008 01:59:21 -0500 Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JB305-0002bJ-8b for emacs-devel@gnu.org; Sat, 05 Jan 2008 01:59:21 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JB2zz-00051X-Ke for emacs-devel@gnu.org; Sat, 05 Jan 2008 06:59:15 +0000 Original-Received: from 169.red-81-35-77.dynamicip.rima-tde.net ([81.35.77.169]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2008 06:59:15 +0000 Original-Received: from ofv by 169.red-81-35-77.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 05 Jan 2008 06:59:15 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 66 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 169.red-81-35-77.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (windows-nt) Cancel-Lock: sha1:0oIOToHVEo7OMCX3TcUB0eaVdtI= 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:86116 Archived-At: Richard Stallman writes: > So perhaps you hack all day, periodically making commits (using "git > commit") which store your changes into the .git subdir. Then when you > later connect to the net, you can merge the new changes in .git into the > remote emacs repository on savannah (using "git push"). > > It sounds like "git push" is the real analogue of CVS commit, > and that this is the closest match-up between the concepts of git > and the concepts of CVS: > > CVS GIT > save file = commit > commit = pull or push > > But I still don't understand what step actually alters the trunk that > users will get by default from the public repository. Does `push' do > that? If not `push', then what? The basis of DVCSs is that every user has one (or more) personal repositories. You work on your own for a period of time as if you were the only one on the project, committing changes to your repository. Then, you decide to share your changes with the rest of the world. For this, you "push" the changes to the "golden" central repository, where other users "pull" them to update their personal repositories. It's just a matter of independent repositories that communicates with each other. "Push" is "send my changes" and "pull" is "get other's changes". Using analogies with CVS here is dangerous and only help to obscure what a DVCS is. As is the case with learning a new programming language, it's better to forget about specific languages you know and think on terms of how useful the language is for you. Often you see that the new language is a big improvement because it solves a problem that you didn't realized until you see it solved. A very important feature is that you are not limited to communicate with the central repository. You can make available your personal repository to other users and so create groups of developers working together on a issue. When the work is done, some of you push the final result into the central repository. Personal repositories and peer-to-peer sharing opens lots of possibilities: you can work on a difficult issue using localy the advantages of having a personal VCS, doing multiple commits as you hack the problem and, finally, "pushing" to the central repository the clean, finished work. As mentioned above, you can share your changes with other people without touching the central repository. You can create as much personal branches as needed for your personal use, as this is a local operation. In fact, some DVCS encourage branching even to implement almost trivial changes, which makes much sense if you ever work on more than one issue at the same time. When your repository communicates with other repo, either by getting (pulling) or by sending (pushing) changesets, a merge is performed. DVCSs uses sophisticated algorithms for tracking merges and remembers which changesets are already merged on every repository. It is possible to get or send a selection of changesets on a consistent way (this is termed cherry-picking), that is, if you require changeset 100 and it depends on changeset 93, the system knows this and takes the appropiate action. -- Oscar