[Cvsnt] general questions.

Fri Sep 28 10:12:13 BST 2001

Adam,
I am still using 1.10.8 because I can't see the benefits yet of moving
to 1.11.1. So have this in mind when reading, there might be features
on 1.11.1 that solves things not possible in 1.10.8 (like
authentication issues)...

1. Path on server
It would be nice to have CVS-NT use a scheme where the location on the
server was symbolic. In my thinking that could be solved by having an
extra registry entry for the repositories, like:
[RepositoryXSymName]=<the real server path to repository top>
Then CVS-NT would parse a call like
:pserver:user at server:myrepository
or
:ntserver:user:myrepository
to the correct location and the user would not have to know where that
is. And the administrator could place the files in any good location.
But this is an issue for the developer, and there might be
compatibility issuse. (Tony???)

2. ntserver vs. pserver
The issue that comes to mind is the difference in security and user
handling. With ntserver the connection is through the named pipe
method and is encrypted. The user is also logged in on his (NT class)
workstation and carries his user information over to the CVS server.
Thus the file system security can be used on a very low level
granularity to control access to CVS repository files.
With pserver the user needs to "log in" to the CVS server and his
password is not very well encrypted. I believe the actual transaction
data are sent completely in the open too, so you will have to be
comfortable with this. Finally the CVS-NT process started by a pserver
user runs in the context of SYSTEM and thus always has access to
everything, so there is no way you can control access for different
users once they have been logged in.
To be able to use pserver securely you must implemnt some form of SSH
systemm, something I tried but abandoned 6 months ago. Too much work
and we use NT only clients anyway.

3. CVS repository on file server
I can't see a problem here really. Put your CVS-NT service on the file
server box and dedicate a separate drive partition on it for the
repository files (no share son this drive please). Set up your backup
to work as usual and you are done.
It is always adviced to have the repository files local to the CVS-NT
server, not on some network drive on the server machine. Doesn't make
sense to have the service on one machine and the files on another
anyway....

4. Network server for CVS files
There are two separate issues here:
4.1 Sandbox files on network drive
This issue is with the way WinCvs finds out which files to show as
modified. WinCvs uses a Windows API that basically puts a watch on a
directory which fires as soon as any file in the directory has
changed. This API works fine on local drives (which are maintained by
the local CPU), but for network mapped drives it seems to
automatically convert to a polling system that creates a *lot* of
network traffic and also ups the WinCvs CPU cycle usage something
awful. If the users will work with WinCvs by starting it when they
want to do some CVS stuff and then immediately closes WinCvs when they
are done then it will be OK to use a sandbox on a mapped drive, but in
my view not otherwise.

4.1 Repository accessed using :local:, or via Windows Explorer(!)
Yes, it is possible to access repository files directly through the
file system if the :local: protocol is used! This bypasses the CVS-NT
server and lets the users manipulate the repository files directly
from their workstations. In my view this is a no-no and the way I have
stopped it from ever happening is by placing the repository files on a
separate partition on the server and by NOT having any shares at all
defined on that drive (except the administrative share used for
backups, but that cannot be accessed by users anyway).
Now the only way to work on the repository is via CVS-NT and I have
yet to see any corruption on the files. People using mapped drives
into the repository report corrupted repository files and other
problems.
But if you and your users are careful and not too many you might get
away with this, but I doubt that you will sleep very well if your data
are anywhere close to valuable.....

Hope this helps,

Bo

On Thu, 27 Sep 2001 21:16:16 +0000 (UTC), Adam Shand
<adam at personaltelco.net> wrote:

>
>hi.
>
>i've spent the last couple days messing around with cvsnt 1.11.1 and
>reading the mailing list archives. over all i'm pretty impressed though it
>does seem a little quirky, especially the gui (adding a repository via the
>"Add" button doesn't seem to work at all, and i haven't quite figured out
>the right order to use "cvsservice -i" without getting error messages).
>
>i have a couple questions (please bear with me i'm a unix guy not an nt
>guy but we want the cvs users to be integrated with our nt domain, hence
>cvs nt).
>
> - i've seen references in the older list archives saying that people have
>   been having problems with 1.11 and went back to 1.10.  what is the
>   offical recommendation now? what are the significant differences
>   between 1.10 and 1.11?
>
> - i'd like to standardize on a CVSROOT hostname and path.  in the future
>   i see this allowing us to migrate to different servers without having
>   to worry about coordinating all the developers checking everything in
>   before the move.  unfortunatey cvsnt's usage of drive letters breaks
>   this.  i thought i might be able to use a windows shortcut like a unix
>   symlink but that doesn't seem to work.  is there anyway to be able to
>   make a CVSROOT of something like ":pserver:adam at cvsserver:/cvsroot" to
>   work regardless of where /cvsroot is on the actual server?
>
> - we need *nix and windows clients to be able to access our repository
>   (why we migrated from vss a few months ago).  are their any issues with
>   having the windows users user the ntserver with wincvs and the unix
>   ones use pserver?
>
> - we'd like to use a file server (a netapp) as our central cvs store.
>   this works well because it makes sure the data is backed up gives us a
>   central point of managment.  the problem is that windows drives are
>   mapped at login time not boot time and cvsnt doesn't seem to support
>   unc paths.  is there any way to make this work?
>
> - i've also seen some messages here saying that using a network file
>   system (either smb or nfs) is a *bad* idea with cvs.  how bad is it?
>   have people made it work, if so how?  people always say that network
>   filesystems are bad but, for example, you can make it work with mail
>   servers (careful mbox locking via procmail or maildir).  are there ways
>   to make it work with cvsnt?
>
>thanks,
>adam.
>

_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt