Re: renaming a directory in the checkout / recursive add and commit for all subdirs

[Greg A. Woods]

[ On Wednesday, September 19, 2001 at 19:30:19 (-0700), Paul Sander wrote: ]
> Subject: Re: renaming a directory in the checkout / recursive add and commit 
> for all subdirs
>
> 'Course, this procedure makes it harder to gather the entire
> version history of any file together into one place (you need to
> check out a new sandbox for every reorg to see it all)

No, you don't have to check out a new sandbox.  All the commit comment
logs and previous revision deltas, old releases, etc. are all
immediately and completely accessible, even without ANY working directory.

>, and
> it's harder to merge between branches if the contributor branch
> didn't have this procedure done at the same time as the destination
> branch.

Huh?  Never been a problem for me (and yes, I've done it multiple
times).  I suppose if someone tried to do a merge without knowing what
had happened they might be in for a bit of a surprise, but provided the
commit comments are meaningful enough they should be able to figure out
what to do quickly enough.

> Another way to handle some of these cases is replicate the RCS
> files in the repository (and delete version tags), but that method
> has its own problems.

Yup.  The problems are almost as serious, and potentially even more
serious if you've got other potential clashes with other "dead" files in
the destination directory.  Never replicate files in the repo and never
make any links (hard or symlinks) in the repo!

> Still another way is to write a new module and hack in the new
> location of the renamed directories.  That solves the problems
> of both methods above, but adds its own set.  For example, all
> users of the new module must perform a fresh checkout, plus you
> must track multiple modules for a single product.

Yes, that works well enough in a few cases, but generally it simply
migrates the problem to a place where CVS has no good support tracking
release relationships (i.e. to the modules file).

It also relies on complex features of the `modules' feature which may
not be stable and which are known not to behave identically on
client-server and local checkouts.

It really is best to keep everything all in the managed files
themselves, and to do the procedure as I outlined it (which is basically
the same procedure to use even if you're renaming one file within the
same directory -- it's always just an add and a remove).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>