[cvsnt] Re: 2.0.46 newbie install questions

[Oliver Giesen]

> 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.  

While CVSNT itself could handle spaces fine, they're still not 
recommended. Especially if you're one day going to add some trigger 
scripts, e.g. to generate commit notifications or something like that. 
The script interface cannot handle spaces in file or path names that it 
passes to the scripts.


> Ah, very good hint.  I removed the nested one, re-imported, and now
> I am getting much better error messages in Tortoise.

Still, why do you think you need multiple repositories? We started out 
with different repositories for different customers and third-party 
sources as well but found that it simply was too much unnecessary 
maintenance overhead and merged them all into one eventually and live 
much more happily ever since...


> 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.

FWIW: Here's a glossary entry I once prepared on the term "CVSROOT":

Unfortunately this term has more than one meaning in the CVS-world (the 
distinguishing terms used below are mostly the author's creation, though 
based on perceived common usage):

The CVSROOT connection string
    Most commonly it is used to refer to the connection string used to 
identify the location and access method of the repository one wants to 
connect to.

The CVSROOT module
    Inside every CVS repository there exists one default module which is 
also named "CVSROOT". This module is located directly below the 
repository root folder. It is automatically created by the Init command 
and contains various administrative files that define the repository's 
configuration.

The CVSROOT folder
    Possibly because the minimum requirement for a syntactically correct 
CVSROOT connection string (see above) is that it contains the path of 
the repository's "root" folder inside the server's file system, many 
people tend to refer to this folder as "the CVSROOT of the repository" 
as well. This is inaccurate but unfortunately still rather common. 


> 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.

Ah yes, that's the modules file. Apart from some rather dirty hacks and 
web-based tools like ViewCvs, it's the only way to see (or "assume" 
rather) what's in the repository of a GNU CVS server without actually 
checking it out. CVSNT however introduced the cvs ls command which 
simply lets you browse the repository contents very similar to a local 
file system. It's therefore no longer necessary to manually list 
physical modules in the modules file. It's still useful for "virtual" 
modules though.


> I want to have a list of users that is totally separate from
> the Windows login list.  

Another thing you might want to reconsider. Reusing Windows user 
accounts will allow you to control access permissions on individual 
files and folders using the standard NTFS mechanisms. It's how CVSNT 
works best AFAICT.


> I reset both services back to running under LocalSystem. Sadly
> the locking service still gives an error.

Hmm, maybe it's time to reinstall from scratch... there seem to be quite 
a few things messed up by now... not entirely sure this will be enough 
to solve it though... BTW: you don't have to delete your repositories in 
the process. Just readd them to the control panel after you've 
reinstalled.


> Some vague sense of giving cvs users as little access
> as possible, by curtailing what the cvs service could do.

The sense is okay but you applied to the wrong suspect... ;) You could 
still limit CVS access but you shouldn't limit the privileges of the 
server in order to do so but those of the individual users themselves 
instead. See above.


> I will need to allow access from Linux clients.  I will have
> a look at sspi first though.

It's available for *ix too but the implementation there is less secure 
(only NTLM1). You are however not forced to use the same protocol for 
all clients. You could have Windows clients connect via :sspi: and *ix 
clients connect via :sserver: .

Hope this helps.

Oliver
----	------------------
JID:	ogiesen at jabber.org
ICQ:	18777742	(http://wwp.icq.com/18777742)