From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6762 invoked by alias); 21 Nov 2001 00:20:23 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 6630 invoked from network); 21 Nov 2001 00:20:13 -0000 Received: from unknown (HELO disaster.jaj.com) (209.64.26.3) by sourceware.cygnus.com with SMTP; 21 Nov 2001 00:20:13 -0000 Received: (from pedwards@localhost) by disaster.jaj.com (8.9.3/8.9.3) id TAA11940; Tue, 20 Nov 2001 19:23:38 -0500 Date: Sat, 10 Nov 2001 07:56:00 -0000 From: Phil Edwards To: "Joseph S. Myers" Cc: Alexandre Oliva , gcc@gcc.gnu.org Subject: Re: Moving C to its own directory (was Re: ObjC tree inlining) Message-ID: <20011120192338.A11889@disaster.jaj.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jsm28@cam.ac.uk on Tue, Nov 20, 2001 at 08:56:31AM +0000 X-SW-Source: 2001-11/txt/msg00465.txt.bz2 On Tue, Nov 20, 2001 at 08:56:31AM +0000, Joseph S. Myers wrote: > On 20 Nov 2001, Alexandre Oliva wrote: > > It would be extremely beneficial, I'd strongly suggest us to break > > this rule in the case of moving the C-specific sources in the GCC > > repository. It would be best to copy all C-specific CVS files to the > > `c' sub-directory, such that you can still do CVS diffs based on > > Doing this thing is a recipe for problems, even if you mark all the old > revisions "dead" and take care to avoid a file ending up both in and out > of the Attic. We haven't done it when moving runtime libraries out to > toplevel, we haven't done it when moving docs to the "doc" subdirectory, > we shouldn't make this case any different. A raw repository shuffle? We did it when libstdc++-v3 was moved into the GCC repo. Hasn't been any difficulty for us. (Okay, granted, there have been times when I wished we'd kept the old repo around for 'annotate', but that's not an issue here.) > Some more advanced version control systems might support renaming files in > a better way, but with CVS we should avoid going behind its back. If it's a documented procedure in the CVS manual, you can hardly call it "going behind its back." Yes, I realize that it's a repository-affecting action that doesn't get logged in CVSROOT/history, but I think it would be better to preserve individual file history by moving the ,v directly. The add&remove method is semantically cleaner, but every C front end file would then be at revision 1. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams