info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Copying/duplicating a repository


From: Simon Renshaw
Subject: RE: Copying/duplicating a repository
Date: Thu, 12 Jul 2007 10:52:40 -0400

Hi Todd,

This is what I tried, not sure how good it is.

First I created the new repo and initiated it.

We use CVS with Eclipse. So I did a checkout. Then I disconnected and
shared it on the new repo.

Anything wrong if I do that beside losing history?

Thanks!
Simon

-----Original Message-----
From: Todd Denniston [mailto:address@hidden 
Sent: 12 juillet, 2007 10:39
To: Simon Renshaw
Cc: cvs
Subject: Re: Copying/duplicating a repository

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.
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]