This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Moving C to its own directory (was Re: ObjC tree inlining)
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- To: Alexandre Oliva <aoliva at redhat dot com>
- Cc: <gcc at gcc dot gnu dot org>
- Date: Tue, 20 Nov 2001 08:56:31 +0000 (GMT)
- Subject: Re: Moving C to its own directory (was Re: ObjC tree inlining)
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
> dates, but deleting all tags from it, since they were not present in
> older releases. Of course, if you check out an old snapshot by date,
> you'll get additional files in the `c' directory that weren't present
> back then, but they wouldn't be used at all, because the Makefile
> fragment for the C language wouldn't be present.
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. It should suffice to ensure
that the log message names the old and new names for each file and that
there are no other substantive changes (other than the move and changes of
names of included headers) to the moved files in that commit.
Some more advanced version control systems might support renaming files in
a better way, but with CVS we should avoid going behind its back.
--
Joseph S. Myers
jsm28@cam.ac.uk