Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Stan Shebs <shebs at apple dot com>]

Mark Mitchell wrote:
> 
> > 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.
> 
> If we just "mv" the files, we will never be able to check out old
> branches.
> 
> I don't think we have a choice; we need to "cvs remove; cvs add".

I agree.  "It's not nice to fool Mother CVS." :-)

I'm not clear on the benefit of moving the C frontend right now.
The original rationales for leaving it alone when the C++ frontend
was moved into a subdir were that a) it was required to bootstrap,
and b) there weren't enough files to bother.  Now that there are
more frontends, the symmetry argument is stronger than it used to
be...

One thing to think about that is that there is the idea (not
sure if it's official roadmap) to integrate all the C dialects
into a single frontend that chooses dialect dynamically.  If
that happens, we'll probably want all the c-*, cp/*, and objc/*
to live together in a single c/ subdir.  Since there will be
much churning at that time, it might be better to move everything
as a side effect of rewriting contents.

Stan