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.
At 10:48 PM 06/28/2004, you wrote: >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. Thanks. >>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). Thanks. I found instructions for the import command in the CVS Essentials book. That did work. BTW I discovered that a project name can include a space as long as it's inside quotes. >>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. Ah, very good hint. I removed the nested one, re-imported, and now I am getting much better error messages in Tortoise. >>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). Yeah, I did figure this out eventually. I was confused between all the paths, variables and command line options having to do with the "cvs" "root". It took me quite a while to figure out the differences. The Windows examples are easier than some of the unix ones, i.e. c:\cvsrepo\CVSROOT is easier than c:\cvsroot\CVSROOT. >>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... Hmm. one set of instructions said it was necessary to itemize the list of modules, in order to enable clients to know what was available for checkout. >>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. I want to have a list of users that is totally separate from the Windows login list. I didn't realize there was a cvs passwd command, okay, that sounds easy enough. >>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. Got it. > > 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 saw the other notes on this - thank you! I reset both services back to running under LocalSystem. Sadly the locking service still gives an error. > > I thought it >>was a good idea.) > >Why? Some vague sense of giving cvs users as little access as possible, by curtailing what the cvs service could do. >>(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. Thanks very much for explaining that. I get it. Reserved Edit sounds fine to me. >>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... I will need to allow access from Linux clients. I will have a look at sspi first though. >Hope this helps. It did, very much so. Thank you. Ann