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.
Ann Lynnworth wrote: > Question 1. > Is there a reason the examples put the repository root in the root of > the drive? I was thinking more along the lines of d:\AppsData\cvsrepo. Actually I think most examples I've come across actually *dis*courage repositories at the drive root. The reason for this however is outdated by now. Some older CVSNT releases used to have problems with root-level repositories but that's been fixed for a long time already. So, to put it short, you are free to put your repositories wherever you like. > Question 2. > Am I supposed to start with nothing, then make a "repository", Correct so far. > then copy > in my files (e.g. my project already exists and I want to know start > using version control on it)? No, no, no! Never just copy anything into your repository. In fact, *never* do anything directly inside your repository! Just try to treat it as a black box. Only ever access it via a cvs client. In order to put an existing source tree under version control, use the import command. If there are binary files (or Unicode or whatever kind of files that have special storage requirements) in your tree you should set up CVSWRAPPERS for them (just search the manual for that term and you'll see what I mean), either temporarily via either the import commandline (e.g. -W "*.exe -k 'b'") or a CVSWRAPPERS environment variable or by permanently setting up a cvswrappers file in the CVSROOT module of your repository (again, not by editing it directly in the repository, but by checking out CVSROOT, then editing the file, then committing it). > I have listed 2 repositories through the CVSNT control panel applet. > /AppsData/cvsrepo = d:\AppsData\cvsrepo > /AppsData/cvsrepo/WebHubDemos = d:\AppsData\cvsrepo\WebHubDemos Don't nest repositories. It will lead to grief sooner or later. Probably sooner. Furthermore, you should rethink whether you really need multiple repositories. Most of the time it's better to have just one repository with multiple modules inside it. > I have CVSROOT environment variable set to d:\AppsData\cvsrepo. This will probably work most of the time but it's generally agreed upon that it's safer to use a proper CVSROOT even for local access, especially on a server where there *could* be other users accessing the repository at the same time. By using the above CVSROOT string you are effectively bypassing the server as by omitting the protocol prefix CVS assumes :local: which basically lets the client act as a server in its own right - thus you'd effectively have two servers serving the same repository simultaneously. Better use something like :sspi:localhost:d:/Appsdata/cvsrepo instead (better yet: define an alias name for your repository using the CVSNT control panel applet and shorten that to: :sspi:localhost:/cvsrepo). Also note that setting the CVSROOT variable on the server is not strictly required. It's only used when you run commands on the commandline directly on the server machine. Most of the time however, you will probably be accessing the server from a remote client and that's where you should set the environment variable (and even there it's not required - just convenient - it's rarely needed and even if it is there are other ways to specify it, e.g. directly on the commandline). > Question 3. > What is a module? Most commonly "module" refers to a folder inside a repository, especially a top-level folder, i.e. a folder that you could checkout without specifying any further path elements. More generally, in many docs a "module" is pretty much anything you could specify on the right hand side of a Checkout command. Besides folders, this includes individual files as well as "virtual" modules, i.e. modules that have no direct physical representation in the repository's file hierarchy, but which are instead only defined by an entry in the repository's modules file. > What is a module list? No idea. Never heard of that term... > Question 4. > How do I encrypt a password for use with pserver? Just use the cvs passwd command to add/change users. It will encrypt the entered password automatically. Better yet, don't specify passwords explicitly at all and simply map cvs users to real Windows user accounts. > Question 5. > Do I need the locking service?? It's recommended nowadays, yes. Otherwise you are bound to get the occasional dangling file locks after crashes (but then again CVSNT doesn't really crash that often - actually it hasn't crashed ever on us for several years). Most people used to run scheduled jobs for clearing those up nightly. > It was running, and now it won't > anymore, perhaps because I set the main CVSNT service to run under a > user account other than LocalSystem. (Was that a bad idea? Maybe. Don't know for sure. Probably... > I thought it > was a good idea.) Why? > (I will want to be able to lock files upon checkout, so I assume I > need this service). That's not what this service does. It makes sure that no two users could access a repository file at the same time in order to ensure data integrity. These "locks" are only temporary. Without the lockserver, CVS would handle this by writing a so-called lockfile into the directory that a user was currently accessing and deleting it when the user's operation was done. If another client process found such a lock file in a repository folder it would wait for it to disappear before it carried on with its own operation. As I mentioned before, this had the drawback that these lockfiles had a tendency to "hang around" for various reasons, effectively leaving the directory they were in inaccessible to all clients. The idea of the lockserver is that it manages these locks completely in memory, therefore, once the service or the whole machine dies, the locks do, too. As for locking files upon checkout, you might want to reconsider this. CVS (i.e. *Concurrent* Versions System) was built specifically to overcome the locking paradigm of its RCS legacy. For the few cases where exclusive access does make sense (i.e. when files could not be automatically merged, e.g. binary files) CVSNT uses the Reserved Edit concept instead which is less restrictive and counterproductive. Just search the archives for details. > Question 6. > Where are the instructions for getting sserver going?? So far I have > only founds notes that it doesn't work very well, but no instructions on > how to configure it. For example, does it share the passwd file that > applies for use with pserver, or not? Sorry, afraid I couldn't help you with that one due to lack of experience with it. What exactly are the reasons you want to use :sserver: though? Unless you need to access the repository from non-Windows clients, :sspi: is usually the more natural choice for a server running on Windows and leagues easier to setup as well I think... Hope this helps. -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)