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