From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [CVS] regex.[ch] missing in CVS checkout Date: 05 Jan 2004 15:22:21 -0600 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87k746rsz6.fsf@floss.red-bean.com> References: <20031223225322.8E9BA612AA@sandy.gi.alaska.edu> <87ad5hr9nl.fsf@tc-1-100.kawasaki.gol.ne.jp> <871xqfl27l.fsf@tc-1-100.kawasaki.gol.ne.jp> <87smivtpg1.fsf@floss.red-bean.com> Reply-To: kfogel@red-bean.com NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1073356625 14840 80.91.224.253 (6 Jan 2004 02:37:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 6 Jan 2004 02:37:05 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jan 06 03:37:01 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 1Adh5Z-0000fX-00 for ; Tue, 06 Jan 2004 03:37:01 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1Adh5Z-0001bx-00 for ; Tue, 06 Jan 2004 03:37:01 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Adi0O-0005Xd-F1 for emacs-devel@quimby.gnus.org; Mon, 05 Jan 2004 22:35:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Adhuq-00085Y-SH for emacs-devel@gnu.org; Mon, 05 Jan 2004 22:30:00 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AdhuF-00079X-Mi for emacs-devel@gnu.org; Mon, 05 Jan 2004 22:29:56 -0500 Original-Received: from [207.115.63.73] (helo=pimout5-ext.prodigy.net) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Adhu4-00072a-3m for emacs-devel@gnu.org; Mon, 05 Jan 2004 22:29:12 -0500 Original-Received: from floss.red-bean.com (adsl-66-73-168-220.dsl.chcgil.ameritech.net [66.73.168.220]) by pimout5-ext.prodigy.net (8.12.10/8.12.10) with ESMTP id i062Rb6R287672; Mon, 5 Jan 2004 21:27:40 -0500 Original-Received: from kfogel by floss.red-bean.com with local (Exim 3.34 #1 (Debian)) id 1AdcB3-0005hY-00; Mon, 05 Jan 2004 15:22:21 -0600 Original-To: storm@cua.dk (Kim F. Storm) Emacs: freely redistributable; void where prohibited by law. In-Reply-To: Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 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:19034 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:19034 storm@cua.dk (Kim F. Storm) writes: > > > There was some talk about also adding a CVS hook to prevent > > > modifications, but I don't know if anything got done. > > I still don't see why this is necessary if emacs is the only > package using those files ... it must be possible to find out > if there are other packages using it (were there other symlinks > to them which have been broken?) I think the idea was to prevent diverging changes? That is, if these versions of regex.[ch] are truly frozen in the Emacs repository, while their maintenance continues on separate copies in another repository, then that's not too bad a situation. But if people start modifying them in the Emacs repository, in ways that diverge from what's happening in their "master" repository, then we have an accidental fork on our hands, and sorting it all out years later can be a real hassle. Thus, the hook's job would be to block any change to these files in the Emacs repository, and print a warning that they should instead be modified in their master repository (perhaps by branching from the point where Emacs's frozen copies came from). Emacs could be updated periodically from the master repository, as appropriate. I'm not advocating for or against this strategy, by the way, merely trying to answer your question. (Or there could be some totally different reason, that someone more familiar with the situation can explain.) -Karl