From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andre Spiegel Newsgroups: gmane.emacs.devel Subject: Re: deleting rcs keywords from emacs sources Date: Tue, 30 Mar 2004 16:22:44 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1080656564.29733.69.camel@localhost> References: <4242667.1080067569994.JavaMail.root@tintin.london.ongenie.net> <20040323214737.GA21737@fencepost> <1080200708.749.486.camel@localhost> <1080329835.5425.617.camel@localhost> <1080472226.749.657.camel@localhost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1080658816 11663 80.91.224.253 (30 Mar 2004 15:00:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 30 Mar 2004 15:00:16 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Mar 30 17:00:04 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 1B8Kii-0004nA-00 for ; Tue, 30 Mar 2004 17:00:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B8Kih-0000JF-01 for ; Tue, 30 Mar 2004 17:00:04 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B8KgG-00081J-Td for emacs-devel@quimby.gnus.org; Tue, 30 Mar 2004 09:57:32 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B8Kg8-00080F-Jb for emacs-devel@gnu.org; Tue, 30 Mar 2004 09:57:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B8Kfc-0007rh-8F for emacs-devel@gnu.org; Tue, 30 Mar 2004 09:57:23 -0500 Original-Received: from [193.113.160.16] (helo=mail.o2.co.uk) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B8K8j-0002Ep-JQ; Tue, 30 Mar 2004 09:22:53 -0500 Original-Received: from [217.224.230.120] (217.224.230.120) by mail.o2.co.uk (7.0.020) (authenticated as andre.spiegel@o2online.de) id 40557866005A0091; Tue, 30 Mar 2004 15:22:46 +0100 Original-To: rms@gnu.org In-Reply-To: X-Mailer: Ximian Evolution 1.4.5 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:21091 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:21091 On Mon, 2004-03-29 at 22:56, Richard Stallman wrote: > The problem with this approach is that the files would only be stamped > when *I* send them out. When somebody gets a file through a different > channel, e.g. via Web-CVS, or because somebody else sends it to him, the > file won't have an identification in it. > > Is it a frequent occurrence for you that people report problems in > versions that of VC they got from CVS in this way, without updating > Emacs as a whole from CVS? Very few of the bug reports that I see > seem to describe such cases. It is hard to tell how frequent this is, because in the past, the files people were referring to always contained version numbers, and so I wouldn't know which path they actually took. Myself, I have just recently built and installed a CVS snapshot of Emacs at a customer site, because we needed some of the new features that are not in any actual release yet. I would assume that such installations occur frequently all over the world, especially since there is so much time between Emacs releases. The installed source files are indeed disconnected from their CVS history. Now, if anybody were to discover a bug in such an installation, in a source file without version headers in it, it would be difficult to track down. I don't have hard numbers for this. I'm referring to potential problems, which might turn out more or less severe. (If I'm anywhere near correct, it ought to be happening already for other files, which I don't maintain, and which never had version headers in them. Only other developers could testify to that.) You say that "very few" of the bug reports you see seem to describe such cases. So, if it actually does occur, and version headers would help with these cases, then that appears to be an argument to keep them, and to solve the problems they cause by some other means.