Re: [jamboost] Re: help with Borland build break

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-03-08 17:46:06

Eric Niebler wrote:

[snip] Can't answer your other questions...

> Can somebody 
> familiar with CVS tell me how to move a file while preserving its 
> revision history?

That question has a complicated answer... This is something I did when we 
reorganized the Boost.Build CVS structure. It goes something like this...

1. Identify the *,v CVS version files you want to move. SourceForge has a 
small note about this in the site documentation.

2. Create a shell script that _copies_ the *,v file to its new location. If 
you are placing it in a new directory those need to get create ahead of time 
through the CVS interface.

3. Grab the latest snapshot of the Boost CVS repository, which is published by 
SourceForge nightly. And copy it to a Linux machine accessible to you.

4. Test the script created in #2 against your local copy from #3. That is run 
the script and make sure you make no assumptions as to where it's running 
from. And check that the file shows up on both locations by doing checkouts of 
that local CVS copy.

...You might also want to post the script to the mailing list so others can 
comment on it. If you are getting the impression that mucking with the CVS 
structure is nasty and dangerous at this point, it's a well founded impression ;-)

5. After the operation of the script is verified... Post a request to the 
SourceForge staff to run your script, and wait for them to run it on the real 
CVS repository.

6. Check that the script did actually do what was intended by doing more 
checkouts of the Boost CVS. If something went wrong go back and make another 
script that fixes the problem, repeat until the results are correct.

...Now that you have the file in both locations...

7. Remove all non-branch tags from the new file. This prevents the file from 
showing up when one does a checkout of previous Boost releases (which are 
tagged). Read the CVS docs for this. Check that this is in fact the case by 
doing a checkout of an old boost release, for example Version_1_31_0.

8. Go through all the Boost code and replace references to the old file with 
the new file.

9. Give the regression test at least one clean cycle to run to make sure the 
changes don't break things. Obviously fix any problems and keep checking the 
regressions.

10. Use cvs to remove the now old file. And check the regressions again to 
ensure that the removal doesn't break anything new.

** An important step not mentioned is that you should tag the complete tree 
before doing any changes just in case ;-)

PS. You might be able to find the script I created when I did the Boost.Build 
CVS restructure if you search the list archives, as an example.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq