From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mike Mattie Newsgroups: gmane.emacs.devel Subject: Re: What a modern collaboration toolkit looks like Date: Sat, 5 Jan 2008 18:14:07 -0800 Message-ID: <20080105181407.6fa67306@reforged> References: <20080101171120.GC3830@muc.de> <20080101.190535.32709273.wl@gnu.org> <20080101182742.GE3830@muc.de> <20080101.192802.05328072.wl@gnu.org> <20080102121745.GD17588@thyrsus.com> <20080104124545.GD16402@thyrsus.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1768739767==" X-Trace: ger.gmane.org 1199585820 19246 80.91.229.12 (6 Jan 2008 02:17:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Jan 2008 02:17:00 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 06 03:17:20 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 1JBL4g-0001Ci-VC for ged-emacs-devel@m.gmane.org; Sun, 06 Jan 2008 03:17:19 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBL4K-0004bu-65 for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 21:16:56 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBL4E-0004bW-7E for emacs-devel@gnu.org; Sat, 05 Jan 2008 21:16:50 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBL4D-0004bC-Bv for emacs-devel@gnu.org; Sat, 05 Jan 2008 21:16:49 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBL4D-0004b6-4j for emacs-devel@gnu.org; Sat, 05 Jan 2008 21:16:49 -0500 Original-Received: from wa-out-1112.google.com ([209.85.146.176]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBL4C-0007di-PF for emacs-devel@gnu.org; Sat, 05 Jan 2008 21:16:49 -0500 Original-Received: by wa-out-1112.google.com with SMTP id k34so11477819wah.10 for ; Sat, 05 Jan 2008 18:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; bh=8ufm1hQne5Vn/rrIv6CCS9bSOcU8WODgDAKwCNXQ0P4=; b=VLJOdxlLpB5j86Hb5n7VwvXd4/eijAupy/iZEUc53fS5gLsc1IcIhMVRpFkSFimevPMx62pRaiRo0MEbF8wPFs3k8SKQu5puZ1Vnu73v5uKgRHZWl1lX8s7EDsEBm6XFodgJbn6akmzSx6sd/OB9CYld9nXQkNDZF5C8uB92RbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=wweELQTUTTgabnvHXt9RTuNwGj6sX2aduvXoXN0Wqmgz21p8a/O+M0ROoYsi+BuZ9biajcmggaQG8hICel6GxD5n+ONn/skjIzA95uo/hENFF01Id6tGYKOC+Rvhi2qUutO+vKyZujQxwO+x7x4rtSuzbUh3JTQRwuHPiFVntl4= Original-Received: by 10.114.58.1 with SMTP id g1mr1851603waa.91.1199585805886; Sat, 05 Jan 2008 18:16:45 -0800 (PST) Original-Received: from reforged ( [71.217.198.62]) by mx.google.com with ESMTPS id m24sm4925479waf.57.2008.01.05.18.16.45 (version=SSLv3 cipher=OTHER); Sat, 05 Jan 2008 18:16:45 -0800 (PST) In-Reply-To: X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i686-pc-linux-gnu) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:86280 Archived-At: --===============1768739767== Content-Type: multipart/signed; boundary="Sig_/SqN/NO4jOToB.jmDz5QX01H"; protocol="application/pgp-signature"; micalg=PGP-SHA1 --Sig_/SqN/NO4jOToB.jmDz5QX01H Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 05 Jan 2008 16:59:13 +0100 Andreas Schwab wrote: > Richard Stallman writes: >=20 > > Currently we recommend that people "build the source from CVS", and > > we don't say "from the trunk" because that is a general convention > > of CVS usage. > > > > If we used git, what convention would replace that? >=20 > It's the same, basically. If you clone a git repository, your > personal repository is automatically set up to track the default > branch of the remote repository, which is normally the master branch. >=20 > Andreas. >=20 take a look at www.kernel.org. I use git for my linux tree.=20 I am what you would call the end-user in this case. My use is alot simpler with git. When a release is pending I check the changelogs via gitweb, do various searches for hardware and sub-systems of interest. If I like what I see I simply cut & paste the git url into a git-pull and merge the upstream changes. On a regular basis I pull from two branches, the first branch being the official linus tree, the second is usually 2.6.x.y for patch releases. Occasionally I need to debug a kernel problem with a pre-release. When this happens if the developer for the sub-system is using git I can pull fixes from his tree while we are diagnosing the problem. Once it is fixed I don't have to revert the changes before I pull from the official repo again, because the maintainer requests a pull from linus, it gets merg= ed, and git doesn't barf on previously merged changes. In fact during this discussion I have noticed a key point that has not been= mentioned. If RMS is wondering how a project is lead with a distributed system the ans= wer is the convention of asking for a pull. I don't think anyone "pushes" changes on Linus. When they have something th= at is in shape for him to review they request via e-mail a pull and give the git URL. Linu= s is then free to look through the history of their branch. He can see not just the w= ork, but the history. That includes all the changes, bugs, and features. By reading the history h= e can get a much greater sense of how it developed, not just a diff. If he likes it, he pull= s it. If not they can keep at it and ask again later. When he pulls he gets the full history. CVS is crippled in that there is no way to record changes before commit. I = personally do not like CVS like systems because it puts a huge burden on the developer th= at actually works really hard to do a clean merge for review. What I consider a clean merge for review to be is this: Broken up into chan= ges where each change can be described succinctly by a changelog, and the change must not = break compile or regress.=20 here is a little constrast sketch: bad commit: add subsystem foo , with new data structure bar, modifying existing code ba= z to use new data structure bar. Good commit: 1. add new data structure bar 2. modify baz to use new data structure bar 3. add subsystem foo. Notice how in the good commit the maintainer of baz can evaluate the new da= ta structure without wading through my new subsystem foo which he probably doesn't care about. If CVS a= nd DVCS systems where compared to writing CVS would not have topics or paragraphs, just one huge body of t= ext. Changes in DVCS systems can be broken up, like a body of text into paragraphs so that people can un= derstand them better. Because CVS cannot record changes in the working copy you have to do one of= two things: A. finish the entire work and publish as a single commit. This alternative = is so broken you actually have to backup your working copy changes yourself. B. break the commit up into valid changes and try and maintain a diff serie= s in the working copy until you can submit the sequence. Again backing up yourself. C. use a branch. Of course people who use CVS will say C is an entirely valid option. It doe= s work. But it discourages casual development and definitely would discourage me. I don't like to make= proposals without code to show. Often until the code is fleshed out I don't have the facts to= make a proposal. With CVS I have to get a commit bit, get a branch (sounds like paperwork), = and finally start hacking away. I consider this high risk because I have to declare my succes= s (proposal + commit bit + branch) before I know if the idea will even work. I would much rather hack away on any distributed VCS where I can pick the g= ood idea from the dozens of ideas that seemed good but did not pan out. When I would go to "request = pull" or merge I can show the entire history of the development. DVCS are not perfect, but they at least make what I call a good commit poss= ible without having to do what I consider absurd labor. When I have to work on a project using CVS= or even SVN I spend a huge amount of time manually slicing and dicing diffs in diff mode. If an= ything goes wrong in the diff sequence I am in big trouble so I also have to keep full copies at= each "change point". At that point It's not a reversion control system for me, it's just a publi= shing tool. All of the changes have to be maintained by hand in diff-mode. What I call good commits has two key points. It feeds changes incrementally= for both review and testing. Who wants to try and test a huge chunk of code dropped in a single= commit ? Doing things the right way usually pays off even in ways you don't anticipate, like git-= bisect. I have personally used that to track down a problem with a IDE driver. I found the broken cha= ngeset in something like six reboots. The fix was in the Linus tree within days. I don't think it works at all to try and describe git in terms of CVS. In f= act dictating how you merge by version control system is kinda supsect as well. The goal should b= e to turn in high quality merges, incrementally reviewed, incrementally merged and tested. An= y change that breaks the compile or test-harness is sin plain and simple. If a project can't mai= ntain that standard with their tools then their tools are a problem. If the developers are so s= killed at flaking diffs from their working copy like cavemen flaking arrowheads from stone, t= hen there is no problem. On the other hand if merging changes is a problem, then there is a *big* pr= oblem. I don't think merging is something you do for release, it's something you do to integrate= the work of a team. If you can't merge you can't work together. If anything branching is for re= lease, not development. My 2 cents at least. Please don't take any offense from any of these statem= ents. No person or caricature was harmed in the writing of this mail. Cheers, Mike Mattie (peanut gallery) --Sig_/SqN/NO4jOToB.jmDz5QX01H Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHgDlvdfRchrkBInkRAsRmAJ9uDLAp0t9mZHsqBOXA/TBOmWy6CwCeOxoA YhU1Lj3H65ogBGApslw+Ry8= =QQij -----END PGP SIGNATURE----- --Sig_/SqN/NO4jOToB.jmDz5QX01H-- --===============1768739767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============1768739767==--