From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: rename and clean unexec.c Date: Fri, 30 Jul 2010 12:30:35 +0300 Message-ID: <83vd7xb9l0.fsf@gnu.org> References: <83hbjjcxex.fsf@gnu.org> <87sk33pdpf.fsf@telefonica.net> <83aapbcoqs.fsf@gnu.org> <838w4vc7gs.fsf@gnu.org> <834oficgpf.fsf@gnu.org> <8339v2c9ea.fsf@gnu.org> <83zkx9bhhm.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1280482290 23620 80.91.229.12 (30 Jul 2010 09:31:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Jul 2010 09:31:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 30 11:31:28 2010 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.69) (envelope-from ) id 1Oelvv-0007ff-GX for ged-emacs-devel@m.gmane.org; Fri, 30 Jul 2010 11:31:24 +0200 Original-Received: from localhost ([127.0.0.1]:50568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oelvr-0000wL-4f for ged-emacs-devel@m.gmane.org; Fri, 30 Jul 2010 05:31:11 -0400 Original-Received: from [140.186.70.92] (port=42055 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oelvh-0000vM-Tl for emacs-devel@gnu.org; Fri, 30 Jul 2010 05:31:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oelvf-0005eJ-G3 for emacs-devel@gnu.org; Fri, 30 Jul 2010 05:31:00 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:32954) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oelva-0005dQ-VG; Fri, 30 Jul 2010 05:30:55 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0L6D00L0066XQB00@a-mtaout23.012.net.il>; Fri, 30 Jul 2010 12:30:31 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.19.236]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L6D00JPI6ETOB40@a-mtaout23.012.net.il>; Fri, 30 Jul 2010 12:30:31 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:128008 Archived-At: > Cc: emacs-devel@gnu.org > From: Dan Nicolaescu > Date: Fri, 30 Jul 2010 03:37:30 -0400 > > Eli Zaretskii writes: > > >> Cc: emacs-devel@gnu.org > >> From: Dan Nicolaescu > >> Date: Thu, 29 Jul 2010 17:18:02 -0400 > >> > >> I am not sure why are so opposed to this. > > > > Not "so opposed", just opposed. I'm opposed in principle to every > > cosmetic change that doesn't have a very good reason. > > Maintainability is a very good reason. Keeping bad names is not. It should be obvious by now that we disagree on how much this particular renaming will contribute to better maintainability. > > That's because > > such changes obscure real code changes and make forensics harder. > > Can you please explain exactly how renaming a file managed by a decent > VCS makes forensics harder? I can only speak about Bazaar, as I'm not familiar enough with similar facilities of other dVCSs. The tools I use for forensics are: . bzr log . bzr diff . bzr annotate . bzr bisect (and bzr revert in general) . ChangeLog entries . related discussions on emacs-devel and bug-gnu-emacs "bzr diff" and "bzr annotate" indeed support renaming nicely and transparently, but they are never enough to fully investigate the reasons for some change. They just show what was changed and when, and who did that, so they are only the starting point. A minor gripe about "bzr bisect" and "bzr revert" is that they will move the renamed (or deleted) files to alternate names, which is fine, but requires one to be alert in order to prevent all kind of weird errors and warnings down the line. The rest of the tools I use have problems with renaming: . The latter two need that you know about the renaming, or else you won't hit relevant information in a search. . The first one generally shows a slightly edited copy of a ChangeLog entry, so it doesn't support renaming well, either; even the entry for the rename itself will only mention the renaming if the committer remembered to state that, i.e. it's prone to human error. In addition, "bzr log" seems to have a bug that rears its ugly head with renamed files. Observe: $ bzr log -c26091 --long src/s/usg5-4-common.h bzr: ERROR: Path unknown at end or start of revision range: src/s/usg5-4-common.h (It works if I use usg5-4.h, the name it had when revno 26091 was committed.) Granted, these are not acute problems, more like annoyances, but if you are in a hurry and need to find the information quickly and efficiently, they could defeat you. Again, I don't object to renaming in general. We renamed (or moved) quite a few files lately, and I don't remember myself objecting to even one of them. I just don't see a good reason in this particular case. Now, I hope that my reasons are clear, as are yours. If only the two of us have opinions on this matter, we could go on arguing forever. I think at this point it would be good to hear opinions from others, preferably Stefan and/or Chong.