From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Sun, 22 Nov 2009 07:11:16 +0100 Message-ID: <873a475bsr.fsf@telefonica.net> References: <87639fr3w7.fsf@red-bean.com> <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <87ws1ku7zd.fsf@red-bean.com> <87hbso4s13.fsf@telefonica.net> <83aaygoy90.fsf@gnu.org> <87vdh36d48.fsf@telefonica.net> <831vjrptha.fsf@gnu.org> <87einr63b6.fsf@telefonica.net> <83y6lzo9e7.fsf@gnu.org> <871vjr750o.fsf@uwakimon.sk.tsukuba.ac.jp> <83tywnnq34.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1258870571 22436 80.91.229.12 (22 Nov 2009 06:16:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2009 06:16:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 07:16:04 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 1NC5jv-0001ip-CJ for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 07:16:03 +0100 Original-Received: from localhost ([127.0.0.1]:35543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC5ju-0005A0-HZ for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 01:16:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NC5hO-0003rY-4i for emacs-devel@gnu.org; Sun, 22 Nov 2009 01:13:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NC5hI-0003oY-A4 for emacs-devel@gnu.org; Sun, 22 Nov 2009 01:13:24 -0500 Original-Received: from [199.232.76.173] (port=49733 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NC5hH-0003o8-Ov for emacs-devel@gnu.org; Sun, 22 Nov 2009 01:13:19 -0500 Original-Received: from lo.gmane.org ([80.91.229.12]:37932) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NC5hH-0004Rd-EG for emacs-devel@gnu.org; Sun, 22 Nov 2009 01:13:19 -0500 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1NC5hF-0001Gm-F4 for emacs-devel@gnu.org; Sun, 22 Nov 2009 07:13:17 +0100 Original-Received: from 153.red-88-24-228.staticip.rima-tde.net ([88.24.228.153]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Nov 2009 07:13:17 +0100 Original-Received: from ofv by 153.red-88-24-228.staticip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 22 Nov 2009 07:13:17 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 50 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 153.red-88-24-228.staticip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) Cancel-Lock: sha1:rDKpCokutQ9FOSoI8EctUiUuk28= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:117486 Archived-At: Eli Zaretskii writes: [snip] >> and you make the >> "obvious" fix and 6 months after *that* somebody inserts an Arabic >> obscenity into a letter to their mother because it's "I love you" >> spelled backwards.... > > A VCS is no panacea from bugs. It is no panacea, but helps a lot. Suppose that some user files a bug report saying: "that piece of elisp code used to work fine until I upgraded to version 23.3 from 22.4." You check that the elisp code is correct and that it fails to produce the right result. Now, if you were able to pinpoint the exact commit where the bug was introduced, it is quite likely that that knowledge will give you a lot of insight on the problem. Having a VCS allows you to do a binary search on the project history for the buggy commit. With CVS it is a bit tricky, but with changeset-oriented VCSs like bazaar or any other modern VCS it is trivial. If you have local access to the project history (the case of Bazaar, git, mercurial... but not Subversion, for instance) the process can be very fast. Those DVCSs even have a specific command for doing the work (in the case of Bazaar, it is a plugin that you install separately). You write a test case and ask the VCS to test it among two points on the project history and report what's the first revision that makes it fail. BTW, one thing that the people who only have experience with CVS does not appreciate, is a changeset-oriented VCS, where the source base transforms on discrete and well defined steps. Among other things, this makes the Changelog unnecessary, as it turns to be the equivalent of `bzr log'. It is necessary to fix some old habits, though. Every commit should be a complete, consistent and unique change: a bug fix, a new feature, some code cleanup, etc. But no more splitting a logical change among several commits or mixing unrelated changes on the same commit. > I'm fine with that, I just said that I don't see how a VCS can "shine" > in my case. Of course I didn't know your specific case when I said that a DVCS is a "shining" tool for you. I hope, however, that after some time you will realize that it can dramatically improve the productivity gain one gets from using a VCS, when you come from VCS. -- Óscar