Re: Copying/duplicating a repository

[Todd Denniston]

Todd Denniston wrote:
> Simon Renshaw wrote:
> > Hi,
> >
> >  
> >
> > What is the best way to copy a repository?
> >
> >  
> >
> > I want to make a copy of a production repository so we can do tests
> > without affecting the real code.

Of course when I re-read your email, I am beginning to think you were asking 
how to use a sledge hammer, when what you may have needed to do was drive a 
screw. I gave you the sledge hammer, but may I suggest you check the thing 
being driven for a slot in it's top, before you hit it? :)

if what you reason you asked the question is along the lines of:
We need to test some ideas out in the source code baseline, without breaking 
current development source code.

The more appropriate tool is a branch.

a branch would segregate the code change, but would make reintegration easier 
when/if it was decided the new changes were good.


The solution I gave below is for testing out things like new management 
scripts on, changes to the config scripts in $CVSROOT/CVSROOT, or playing with 
understanding how you want to import some external code.

> Here is how I would do it:
> 0) have everyone else stay out of the repository for a little while.
> 1) make _TWO_ good backups of the repository, and verify they are good.
> 2) take one of the backups and restore it to a new directory/machine.
> 3) make sure that nothing in $CVSROOT/CVSROOT of the NEW repo points to 
> scripts/info files in the OLD repo.
> 4) make sure if you have other scripts which work with your repo, that 
> you get copies of them and appropriately modify.
> 5) Assuming you are not using pserver, just update your $CVSROOT value 
> to point at the new test repo.
> 6) have everyone else stay out of both repositories for a little while 
> longer,
>     a) run some test cvs commands that write to the repo, like `cvs 
> tag`, and make sure only the new test repo changes.
>     b) any of the scripts you use against the repository, and make sure 
> only the new test repo changes.
>     c) decide if you want to run (a) & (b) from a "normal" account and 
> verify this time it is the original repo that changes.
>     d) decide if you need to fix something and how (you might want to 
> use a backup to restore the original repo if you did (c) ).
> 7) let everyone know they can go back to work with the repo.
> 8) let your nerves settle.
> 9) make a new good backup of the test repo so, if you break it good, you 
> don't have to stop work on the normal one again to restore it to this 
> point.
> 10) break the testing repo. :)


--
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter