Re: Any consequences over removing a subdir permanently?

[Todd Denniston]

S I wrote:
> 
> Thank you as always.
> 
> Do you think though that deleting a dir and later retrieving a dead file
> would confuse the dead file where to implant itself?  

Well ... if you "rm -fr"'d the directory structure the file was in, you'll
likely be confused yourself, because not only is there no dead file to
retrieve but there is no attic. :)

This is the reason it is _usually_ a _very_ BAD idea to remove things from
the repository.  Because when they are gone from the version control file
system / database they are GONE, NOT COMING BACK, DESTROYED.

> I have a dummy
> repository and I'm going to try this to find out the outcome.

That is good practice, keep it up. :)

> 
> The subdirs I speak of are about 5 years old and don't think anyone would
> care.  

Be SURE, don't just think it. 8O

> We have restructured our code so many times and we may soon port over
> to a completely clean repository without its history.  So in our case it
> shouldn't matter but I see your point about NOT exercising this.

A middle ground might be:
1) tell everyone to commit all changes they have currently.
2) backup to cold storage media.
3) copy the CVS tree to a new location.
4) do a checkout from the new location and then do a `cvs watch on -R`
against that checkout.
5) find and mark all the directories in the new copies location read only,
and setup a lockdir for it so people can do readonly checkouts. (lock it
down)
6) again backup to cold storage media.
7) remove the unused directories.

This should leave you with a copy in the new location for people who need to
know the ancient history, a copy to recover from if you hit enter on the rm
in the wrong directory, and a smaller repo but with all the history since
the each of the files were last restructured.

> 
> Thanks. :)
> 
<SNIP>
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter