Upgrading
Version 1.11.X to Version 2.0.X
1. Have all users commit their pending changes on all sandboxes served by the PC you are about to upgrade. This is not strictly required - you can skip this step - but serves as a good foundation point for the CVS services. You are about to upgrade the server significantly and while all pending changes *should* survive just fine there may be something that happens to catch your particular environment
2. Shutdown the current server processes
3. Backup your repository (copy all the files). This is not strictly required but a good idea no matter what change you are making to the CVSNT server PC
4. Uninstall the current CVSNT server software. The reason for the uninstall is that 2.X CVSNT uses a completely different installer engine and it must be installed from scratch to work going forward
5. Install the new CVSNT server software
6. Open the CVSNT control pannel applet, visit the Advanced tab and specify a Temporary Directory for the LockService to store files in
7. Add your old repository root on the Repositories tab. You can also change your environment to use Repository Prefixes at this point but current sandboxes will need to be reconfigured at that point. This is discussed in Bo Berglund's InstallationTips
8. Visit the Services Status tab and start the CVSNT Lock Service
9. Start the CVSNT Service
10. See the Notes and Issues section below for further items you may need to address
Notes and Issues
* Having come from an older version you likely were using LockDir in you config file which means CVSNT was storing locking information during commits intermingled with the archive files. You will want to edit the config administrative file and comment out LockDir while at the same time making sure that the LockServer variable is set, most likely to localhost.
# Put CVS lock files in this directory rather than directly # in the repository. #LockDir=c:/cvslocks # Maintains a list of live locks on the repository # (CVS 1.11.1.3 Build 57i and above) LockServer=localhost
* -m 'COPY' functionality in cvswrappers is no longer supported in 2.0.X releases. You probably don't use this but if you do you will have have to change to -k 'b'.
* Email notifications appear to be case sensitive now which means users can start getting notify emails on their own commits to watched files assuming you have notify turn on in some kind of limited fashion: cvs edit -c file [edit file] cvs co file [get email that a watched file was edited]
This can be fixed by putting logic in your notify handler script to compare TO and FROM case insensitively before sending. You must have some handler to get notify working at all under Win32 so this should be no problem...
* If you use ViewCVS you will need to upgrade that to the latest version as well. Log output has changed and older ViewCVS versions will choke.
* commitinfo now sends file names on STDIN instead of the command line. A good thing for large commits but this requires updates to commitinfo scripts if you run them. [loginfo is unchanged though I wish it would not use the cmd line since that is where large actions also occur. --Aric]
* Newer releases of CVSNT have stopped supporting the old :ntserver: connection protocol. If you used that before then you need to switch your users to :sspi: instead. :sspi: works like :ntserver: concerning the way users are authenticated (via the Win32 workstation login) but communicates with the server only through pure TCP/IP on port 2401. So :sspi: is actually routable which :ntserver: never was.
This change is one reason why developers should commit outstanding modifications before your server upgrade. This protocol change affects the CVSROOT variables stored in every sandbox's cvs\root files. If developers commit all changes and you upgrade they can simple checkout again when the upgrade is done and continue working. This has the nice benefit, in my opinion, of cleaning out the cruft that often builds up in long used sandboxes.
The other way to react to changing CVSROOT variables is by running a script down each developer's sandbox to fix up the out of date cvs\root files. WinCVS also has a macro to do this.
* You may want to take this opportunity to switch from drive/path CVSROOT specifications to using Repository Prefixes. I personally do no use repository prefixes but I do know they are more portable. Again, if all developers commited their changes before the upgrade you will not have to worry so much about the CVSROOT change moving to repository prefixes entains.
See Bo Berglund's InstallationTips for more information.
* Installing and uninstalling CVSNT will not affect your repository at all. The repository files are treated as data by CVSNT and are never touched by any install/uninstall.
* Repository files will gracefully upgrade to newer versions with their new features.
Version 2.0.X to Version 2.0.Y
1. Have all users commit their pending changes on all sandboxes served by the PC you are about to upgrade. This is not strictly required, especially on a point release update, but a good idea similar to file backups
2. Shutdown the current server processes
3. Backup your repository (copy all the files). This is not strictly required but a good idea no matter what change you are making to the CVSNT server PC
4. Install the new CVSNT server software over the top of the old version
5. Visit the Services Status tab and start the CVSNT Lock Service
6. Start the CVSNT Service
7. See the Notes and Issues section below for further items you may need to address
Notes and Issues
* Installing and uninstalling CVSNT will not affect your repository at all. The repository files are treated as data by CVSNT and are never touched by any install/uninstall.
* Repository files will gracefully upgrade to newer versions with the new features.