directory restructure + making a long-lived branch the trunk

[Ross Bencina]

Dear CVS Gurus

I've been using CVS casually for a few years, but have joined this list in
search of a solution to a less than casual problem. The mailing list page
(http://mail.gnu.org/mailman/listinfo/info-cvs) recommends an FAQ, but
doesn't provide a link to it. I found some FAQs, but not necessarily The
FAQs. So, if my question below is in an FAQ, please accept my humble
apologies and point me in the right direction.

My problem is this: 2 years ago a branch was created to develop a new
version of our library (www.portaudio.com). This branch has diverged
massively from the previous version, and will soon become the new main-line
release. Before the release we have decided to restructure the directory
tree, and the branch development needs to appear as the trunk.

To change the directory structure, my understanding is that I can just move
and re-name files in the repository so long as I don't care about being able
to check out old revisions with the correct file names or in the correct
directories (we will keep a copy of the module for this purpose).

With regards to making the branch the trunk, what I think I would like to do
is re-write the revision history so that the new (rewritten) revision graph
shows what we currently call the branch as the trunk. That way the last 2
years of revisions will appear to be on the trunk. This avoids having a
discontinuity between branch development, and its resumption on the trunk. I
havn't found any scripts to do this yet, but I'm guessing I can hack
something up if necessary. Alternatives that I know of include starting a
new module (leave old revisions in old module, have no revisions in new
module), or simply merging the branch onto the trunk (revision history is
available, but only when checked out from the branch.

My intuition is that I'm thinking outside the paradigm of CVS and that I
should probably just take the best-practice approach. Except I don't know
what that is. Can anyone offer any insights or caveats about the approaches
I've mentioned, or suggestions regarding what they would do in this
situation?

Many Thanks

Ross.