[cvsnt] Re: 2.0.46 newbie install questions

[Oliver Giesen]

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)