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.
Adam, I am still using 1.10.8 because I can't see the benefits yet of moving to 1.11.1. So have this in mind when reading, there might be features on 1.11.1 that solves things not possible in 1.10.8 (like authentication issues)... 1. Path on server It would be nice to have CVS-NT use a scheme where the location on the server was symbolic. In my thinking that could be solved by having an extra registry entry for the repositories, like: [RepositoryXSymName]=<the real server path to repository top> Then CVS-NT would parse a call like :pserver:user at server:myrepository or :ntserver:user:myrepository to the correct location and the user would not have to know where that is. And the administrator could place the files in any good location. But this is an issue for the developer, and there might be compatibility issuse. (Tony???) 2. ntserver vs. pserver The issue that comes to mind is the difference in security and user handling. With ntserver the connection is through the named pipe method and is encrypted. The user is also logged in on his (NT class) workstation and carries his user information over to the CVS server. Thus the file system security can be used on a very low level granularity to control access to CVS repository files. With pserver the user needs to "log in" to the CVS server and his password is not very well encrypted. I believe the actual transaction data are sent completely in the open too, so you will have to be comfortable with this. Finally the CVS-NT process started by a pserver user runs in the context of SYSTEM and thus always has access to everything, so there is no way you can control access for different users once they have been logged in. To be able to use pserver securely you must implemnt some form of SSH systemm, something I tried but abandoned 6 months ago. Too much work and we use NT only clients anyway. 3. CVS repository on file server I can't see a problem here really. Put your CVS-NT service on the file server box and dedicate a separate drive partition on it for the repository files (no share son this drive please). Set up your backup to work as usual and you are done. It is always adviced to have the repository files local to the CVS-NT server, not on some network drive on the server machine. Doesn't make sense to have the service on one machine and the files on another anyway.... 4. Network server for CVS files There are two separate issues here: 4.1 Sandbox files on network drive This issue is with the way WinCvs finds out which files to show as modified. WinCvs uses a Windows API that basically puts a watch on a directory which fires as soon as any file in the directory has changed. This API works fine on local drives (which are maintained by the local CPU), but for network mapped drives it seems to automatically convert to a polling system that creates a *lot* of network traffic and also ups the WinCvs CPU cycle usage something awful. If the users will work with WinCvs by starting it when they want to do some CVS stuff and then immediately closes WinCvs when they are done then it will be OK to use a sandbox on a mapped drive, but in my view not otherwise. 4.1 Repository accessed using :local:, or via Windows Explorer(!) Yes, it is possible to access repository files directly through the file system if the :local: protocol is used! This bypasses the CVS-NT server and lets the users manipulate the repository files directly from their workstations. In my view this is a no-no and the way I have stopped it from ever happening is by placing the repository files on a separate partition on the server and by NOT having any shares at all defined on that drive (except the administrative share used for backups, but that cannot be accessed by users anyway). Now the only way to work on the repository is via CVS-NT and I have yet to see any corruption on the files. People using mapped drives into the repository report corrupted repository files and other problems. But if you and your users are careful and not too many you might get away with this, but I doubt that you will sleep very well if your data are anywhere close to valuable..... Hope this helps, Bo On Thu, 27 Sep 2001 21:16:16 +0000 (UTC), Adam Shand <adam at personaltelco.net> wrote: > >hi. > >i've spent the last couple days messing around with cvsnt 1.11.1 and >reading the mailing list archives. over all i'm pretty impressed though it >does seem a little quirky, especially the gui (adding a repository via the >"Add" button doesn't seem to work at all, and i haven't quite figured out >the right order to use "cvsservice -i" without getting error messages). > >i have a couple questions (please bear with me i'm a unix guy not an nt >guy but we want the cvs users to be integrated with our nt domain, hence >cvs nt). > > - i've seen references in the older list archives saying that people have > been having problems with 1.11 and went back to 1.10. what is the > offical recommendation now? what are the significant differences > between 1.10 and 1.11? > > - i'd like to standardize on a CVSROOT hostname and path. in the future > i see this allowing us to migrate to different servers without having > to worry about coordinating all the developers checking everything in > before the move. unfortunatey cvsnt's usage of drive letters breaks > this. i thought i might be able to use a windows shortcut like a unix > symlink but that doesn't seem to work. is there anyway to be able to > make a CVSROOT of something like ":pserver:adam at cvsserver:/cvsroot" to > work regardless of where /cvsroot is on the actual server? > > - we need *nix and windows clients to be able to access our repository > (why we migrated from vss a few months ago). are their any issues with > having the windows users user the ntserver with wincvs and the unix > ones use pserver? > > - we'd like to use a file server (a netapp) as our central cvs store. > this works well because it makes sure the data is backed up gives us a > central point of managment. the problem is that windows drives are > mapped at login time not boot time and cvsnt doesn't seem to support > unc paths. is there any way to make this work? > > - i've also seen some messages here saying that using a network file > system (either smb or nfs) is a *bad* idea with cvs. how bad is it? > have people made it work, if so how? people always say that network > filesystems are bad but, for example, you can make it work with mail > servers (careful mbox locking via procmail or maildir). are there ways > to make it work with cvsnt? > >thanks, >adam. > _______________________________________________ Cvsnt mailing list Cvsnt at cvsnt.org http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs