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

[Phil Edwards <pedwards at disaster dot jaj dot com>]

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