cvs re-export

[Luka <luka@MIT.EDU>]

i'm tentatively planning to re-export the cvs module
/d9/projects/walkthru around this week friday.  i'm
convinced this is about as ideal a time as possible.
(the tree's been stewing for a good 4+ years, and
everything i've reviewed is about as stable/quiescent
as it can get.)

sections below: you should read 'process' below for
general info, 'implications' for how it will affect
your code, and 'preparation' for how to keep it from
affecting your code badly.

process:

0. before friday, we prepare for this exercise, as described
   in 'preparation' below.

1. i declare the tree locked for at least several hours.
   (shouldn't really take more than about 1 hour, but i've
   never gotten this perfect the first time in the past, so
   i leave myself slack.)

2. i tag for export.  i 'cvs export' the walkthru module to
   get a working copy the transfer.  it will implicitly have
   empty dirs prunes.

3. i move the actual walkthru module dir aside to something
   like walkthru.old, for archival purposes.

4. i 'cvs import' the working copy to a fresh 'walkthru'
   module directory.

5. i declare the new tree open for business.

implications:

- old working checkouts will become pretty darn near
useless.  you should expect to do a full clean checkout
after the re-export is complete.  (if absolutely necessary
later on, old rediscovered trees can get still retargetted
at the archival for analysis.  but this is not fun.)

- the new tree will lack any history information prior to
the re-export, but that history will still be accessible
(inconveniently) via the walkthru.old archival.

- the new tree will be pruned: any dirs that contained no
files in the old tree will disappear.  this ought to be
normal cvs behavior but may surprise you if you didn't
expect it.  see 'preparation' below for more info.

- according to my calculations, the new tree will be about
1.5 GB smaller (less than 1/4 of the size it is now).
thereby all future cvs operations should speed up at least
a little, many by a factor of 4 or more.  (hence the reason
we like to do this sort of thing occasionally, and the
reason we curse cvs for making us have to do it in such a
clumsy way.  yes yes.)

preparation:

1. notice
probably tomorrow, after a little while for any feedback
from you folks on this list, i will check the history logs
and send mail about this plan less-tentatively to bmg plus
to anyone else who has used the tree in the last few months.
(so they all know why any working copies they may be
hoarding are about to get screwed.)  seth, let me know if
there's anyone else i should also include that's not
obvious from the history.

2. pruning
everyone should take clean checkouts of anything they're
specifically working on using "cvs co -P walkthru[/whatever]'.
the '-P' makes empty directories not appear, which is the
default if you are on any branch, but not on mainline, hence
the reason it may suprise people.  do a full build of said
stuff you like and make sure it deals with the pruned dir
structure.  if it turns out there are empty dirs you do want
to keep (say, where generated binaries are put but your
makefiles don't force dir creation), just go into those dirs
(after making them exist with 'cvs up -d <dirname>') and
do a 'touch .cvskeep'.  it's not a magic filename, just a
commonly used one.  'cvs add .cvskeep' and 'cvs commit' to
get that into the repository.  afterwards, the directory will
have some subtle content and continue to exist.  this
practice should be followed consistently in the future as
well, btw (but it is preferable to make your system not
depend on empty dirs existing).

3. stability
as only half-implied by (2), make sure it builds.
then make sure it runs and you are happy with stability,
because you're about to lose history data.  if you don't think
you can get your code stable enough to handle re-export by
friday, talk to be ASAP, so we can either work around that
part of the module or change the re-export plan.

that's it.  if you have any comments/concerns at all, contact
me at will.  (cc the list if it's of broad interest.)

-pl