My notes on a project involving migrating CVS from Linux to Windows 2000 using the CVS-NT package.
See Also: UsingWinCvs, UsingCvs, CvsLesson, CvsNtAdministration, CvsNtModified, CvsReference
Motivation for CVS under NT:
- The main motivation for running CVS under NT instead of Linux is account integration into our NT Domain. I couldn't find any "nice" way of doing this under Linux, all the solutions I could find involved custom hacks to CVS to support PAM, didn't seem to have wide adoption and were maintained by a single person. Since I am not a programmer I needed a solution which was large enough that it was unlikely to lose community support.
Installing CVS NT:
Download CVS NT from http://www.cvsnt.org/
Migrating Data from Unix to NT:
Managing CVS NT:
Problems We Encountered:
- We couldn't use the ntserver protocol because we needed to be able to access the repositories from Unix boxes (which is the main reason we moved to CVS and away from Visual Source Safe to start with).
- Moving our repository from Linux to NT when we just tar'd it up and moved it we had problems with new line conversion. Instead of doing this you should checkout the CVS modules and import them to the new server and CVS will take care of the problem.
Wanting a standardized CVSROOT to facilitate moving servers in the future. Shortcuts aren't supported (to work like symbolic links in Unix) and UNC isn't supported either. This is all complicated by the fact that CVS clients have to now the root path to the repository which is, IMHO, stupid repositories should live inside the equivelent of Apache's DocRoot and all client paths should be relative to that. Anyway after reading through the list archives
I discovered that you don't have to specify the drive letter in the CVSROOT setting if CVSNT is installed on the same drive as your repositories.
Random Notes for Later Integration:
In ntserver there is an API for this (ImpersonateNamedPipeClient) and it works OK, if only over local connections. For pserver it's a bit of a hack (create a process token manually and impersonate it).. it still works most of the time, as long as the CVS service has 'create a system level token' privilege* (default for System user).
- SMB has latency issues with locking, so a file will remain locked after the last cvs process has stopped using it. This can cause commits to fail randomly. Directory creation is not atomic over a network, as the data is often cached, and cvs might miss the fact that another process has created the directory. Basically the same issues exist over SMB and NFS, and there's plenty been written about the non-advisability of running cvs over NFS.
OK, to make a things a bit cleaner and avoid polluting the root of C:, which I don't like doing, you can setup the CVS_PASSFILE environment variable to point to a fully qualified name of the file you wish the CVS client to use for holding password and login information. I set mine to <cvsroot>\cvspass
- If you're using 2000 you can probably do what you want. A drive can be mounted at mount point on another NTFS partition with the disk administrator (so a drive could be mounted as c:\cvsroot). In the W2K resource kit there is a program called linkd which actually creates symbolic links between directories which could mean that you could mount z:\some\path at c:\cvsroot. I'm not sure, but perhaps /cvsroot would then be interpreted as c:\cvsroot and /cvsroot could be anywhere you want. -- John Hall
- A domain user belongs to the Everybody group per default and also per default the Everybody group will have full control on a disk directory on a domain connected PC. But this is only initially, first create a directory d:\CVSREPO and then set the permissions for the directory to only include SYSTEM and a group "CVSUsers". Now this directory cannot be accessed by anyone not belonging to these two entities, including domain admins (unless they are part of the CVSUsers group. Any directory you create below this will inherit the security properties from its parent so you are almost done here. -- Bo Berglund
Additional Links
Installing ViewCVS with CvsNt
24 November 2003 - Update
You can now use mapped network shares in CvsNt with a hacked version of the CvsNt control panel. Follow the directions at CvsNtModified.
21 February 2003 - Update
We have now deployed CvsNt for one of our repositories, and are in the process of doing so for our main CVS server. To work around the problems with storing the data on the NetworkAppliance we are purchasing a VLD (soon to become iSCSI) license for our Netapp. This will allow us to setup a volume on the Netapp where qtrees can appear to be local disk to Windows servers. Time will tell how well this actually works.
25 March 2002 - Update'
CVSNT now supports hiding a portion of the CVSROOT from the user (*finally* someone fixes this for CVS, thank you! :-). This solves one of my biggest gripes about running CVS under NT.
On the downside it appears that UNC in the CVSROOT is no longer possible (you get a popup saying that you can't do it), which pretty much makes this version of CVSNT useless to me as we store our CVS data on a Netapp. I tried modifiying the registry directly but still no joy.