Re: attic files

[Kaz Kylheku]

On Tue, 1 Oct 2002, Schwenk, Jeanie wrote:

> How can I retrieve a large quantity of Attic files?  A vendor did a merge
> down the vendor branch and, as it turns out, did a reorganization of some
> files.  The resulting commit moved many, many files in many directories into
> their respective attics.  In the meantime, an engineer here, made changes to
> some of those files that were moved to the attic.  He just came over and
> asked me why "Attic" was in the path to the files he had changes.  We need
> these files (even though the vendors don't) and when a fresh checkout is
> done, we need these files.  If I just get a backup, we'll lose all the
> changes that were made recently.  

Avoiding this sort of disaster is one of the reasons I wrote a program
called Meta-CVS.

In Meta-CVS, if you locally modify a file, and then execute an update
which happens to removes it, that file is not lost. Merely, its name is
removed from the mapping (or unlinked, to borrow a Unix filesystem
term).  What you can do in this situation is execute ``mcvs restore'',
then look for your file in the ``lost+found'' directory off the project
root, where it appears under a cryptic name.  One way to do that is
simply to change to ``lost+found'', then do a ``mcvs diff'' to see
which of the restored files there have local modifications. Use ``mcvs
mv'' to move your files somewhere out of lost+found and reassign
meaningful names to them.  Then ``mcvs rm -R lost+found'' from the root
to send all the remaining restored files back to the realm of the dead.

There is a more permanent way to delete. Executing ``mcvs purge'' will
hunt down unmapped versioned elements and actually do the low-level
``cvs rm'' on them.  This can be done from time to time to reduce
the checkout size of the project.

But, of course, since Meta-CVS handles renames properly, rather than
emulating them with a remove and add, you won't get into this situation
very much at all, except when there occurs a true disagreement between
someone still working on a file, and someone wanting to get rid of it.

The software has a sane vendor import feature in the from of a ``grab''
command.  This function figures out the reorganization performed in
your third-party snapshot. It works with regular branches or the main
trunk, rather than vendor branches, so you can properly track multiple
snapshot sources. 

What would have happened under Meta-CVS is that the vendor's file
movements would simply have been integrated into the grab branch
representing that vendor's code stream.  Then upon merging down from
that branch, the renames would have been propagated to the trunk.

When such structural changes are committed, and users update them,
their local sandbox is rearranged to the new structure, without losing
their local modifications.  If you do some hacking on foo.c and an
update then moves it to src/foo-main.c, then src/foo-main.c still
contains your local modifications that you can review and commit as
usual.

Imagine a picture of the world drawn by a child's hand in colorful
crayons, depicting stick figures holding hands under a yellow sun, in a
garden with giant flowers next to a cute little house. This is
essentially what it's like to use this program. :)