Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Sat, 16 Oct 2004 13:56:19 -0400, "Albrecht John" <albrecht_john at bah.com> wrote: >We are going to move our cvs repositories from a win2k server to win 2003 >server. Is it safer to have all projects commit changes back to the server, >release their local workspace, then check back out when the new server is >ready? Yes, this makes things easier for you and gets clean sandboxes too. But be aware that there might be people who have not yet added all new files to their projects so when checking out anew they might not build. I would wait with the release part until checked.... You could start out by having them commit everything, then checking out to another location to verify that all files are there and that the projects build OK. Only then you proceed. It would be a good advice anyways to do so regularly since new files have to be manually added and might be forgotten. >I realize that the local cvs control files can be modified on each >developers pc, but I'm concerned that about manual errors if there are too >many locations to change? There are macros to perform the root changes recursively for you, so the problem is not that bad. If you use WinCvs as client then it is a real breeze to do. > >Or would export/import work better? Does it have any draw backs? This would definitely NOT be a good solution at all! Import explicitly will get you back to square qone (= rev 1.1) on ALL project files with no history at all... Import *creates* a new module with contents and all of the files are rev 1.1 or rev 1.1.1.1 depending on the settings for import. No older revisions will ever be reachable! DIFFERENT APPROACH If the old server will be taken out of operation or renamed you can do the following instead and it will not need any work on the user side: 1) Shut down the CVSNT service on the old server 2) Copy over the repository files (all of them) to the new server 3) Bring down the old server altogether from the network 4) Modify the DNS server record for the old server so that the name points to the IP of the new server. 5) Start the CVSNT service on the new server. Now all client sandboxes pointing to the old server will actually call the new server through the name-IP resolution of the DNS server in your network. No need to change anything at all at the clients. HOSTS If you don't have a DNS server then you can tell the users to add an entry to their local hosts file with the new server's IP and the old server's name.. This is how I do it with my own server that is on the Internet via the firewall (which uses DHCP to get its IP address). When my ISP changes the IP address I just update the hosts file and can continue working. /Bo (Bo Berglund, developer in Sweden)