From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: deleting rcs keywords from emacs sources Date: Tue, 23 Mar 2004 16:47:37 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040323214737.GA21737@fencepost> References: <4242667.1080067569994.JavaMail.root@tintin.london.ongenie.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1080079058 29362 80.91.224.253 (23 Mar 2004 21:57:38 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 23 Mar 2004 21:57:38 +0000 (UTC) Cc: emacs-devel@gnu.org, spiegel@gnu.org, miles@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 23 22:57:27 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B5ttn-0001jd-00 for ; Tue, 23 Mar 2004 22:57:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B5ttn-0008ET-00 for ; Tue, 23 Mar 2004 22:57:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B5trn-0007nr-Bq for emacs-devel@quimby.gnus.org; Tue, 23 Mar 2004 16:55:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B5tqd-0007iI-M6 for emacs-devel@gnu.org; Tue, 23 Mar 2004 16:54:11 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B5tq5-0007Tk-ML for emacs-devel@gnu.org; Tue, 23 Mar 2004 16:54:08 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B5tol-0006yw-4X for emacs-devel@gnu.org; Tue, 23 Mar 2004 16:52:15 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1B5tkH-0000II-NX; Tue, 23 Mar 2004 16:47:37 -0500 Original-To: spiegel@genion.de Content-Disposition: inline In-Reply-To: <4242667.1080067569994.JavaMail.root@tintin.london.ongenie.net> User-Agent: Mutt/1.3.28i Blat: Foop X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20821 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20821 On Tue, Mar 23, 2004 at 06:46:09PM +0000, spiegel@genion.de wrote: > > if they're actively tracking CVS, they can easily > > enough get the cvs revision with `cvs status'). > > Is that really the only answer? To find out what version of a file you are > looking at, you need to be hooked up to the version control system? In general, the version of a single file is not what you want for bug reports, you want the state of the entire _system_. There are several reasons for this, e.g. (a) it doesn't rely on the the bug-reporter knowing what the relevant file is (which they often get wrong, even if they think they do), and (b) many problems which manifest in a particular piece of code are actually due to changes outside it, or interactions between changes in both places. Really you want bug reports to come from M-x report-emacs-bug, unless the submitter is very knowledgeable, as that will make sure to include other info that will tell you the state more exactly. If someone is using a packaged distribution of emacs, then it should be set up to generate a meaningful emacs version number, which will tell you what snapshot of the source tree it is from. The only other common case (AFAIK) is that someone is actively tracking emacs CVS; in this case, you probably _still_ want to know the state of the whole system for the reasons stated above, but the version reported by M-x emacs-version is not very useful (it effectively just tells you "CVS sometime after this release"). However, you also know that in this case both that the user has CVS info easily available, and is probably more knowledgable than average (so probably _knows_ they have CVS info available). So given this, I think we ought to (1) encourage people to use M-x report-emacs-bug, (2) find a way to make M-x emacs-version give more useful info for CVS checkouts (easy for arch though). > I often send files back and forth, and frequently I need to decide what > version I'm looking at, with the file being isolated from its version > control history. Er, if you're making changes outside of CVS than the keyword info isn't going to be very useful, is it? > I find it completely natural, even essential that a file is stamped with the > version it contains, the stamp being a part of the actual contents of the > file. I've seen others say this too, and I suspect that's a major reason people use rcs keywords -- it gives them warm fuzzies. > It should be the job of the version control system to ignore this kind of > changes for operations where it clearly doesn't make sense. CVS, as > somebody pointed out, is capable of this for the headers it produces. It's too much of a tar pit: it means that the V.C.S. is _changing_ the contents of the file, which is _dangerous_ (see the CVS documentation for details); arch uses the much more robust model that what you put in is exactly what you get out. These keywords are the sort of thing that may seem like a great idea at first, but which come back to haunt you later (as we now see :-) -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia