[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS and AFS

From: Derek R. Price
Subject: Re: CVS and AFS
Date: Fri, 15 Jun 2001 09:25:08 -0400

Charles Karney wrote:

> We use CVS in a mixed Windows and Linux environment.  Recently we switched
> from accessing the CVS repository vis ssh to a Linux machine on which
> CVSROOT was a local disk to having the CVS repository in AFS and having all
> clients access this as a local file system.
> The motivation for this change was
> * to simplify user authentication;
> * to allow finer grain control over access to the repository.

People will often be flamed on this list for using a shared network drive 
containing a repository.  At _best_, if your
AFS software is good, you probably want to use ssh access to your Linux server 
which keeps the repository in AFS space.  Search
the mail archives for more.

If you want simplified authentiction you might consider the Kerberized CVS 
client, but I've never tried building it under
Windows.  Assuming you've been using Kerberos with AFS, you probably have most 
of the hooks in place.

> While things are basically working OK, we are running into some problems as
> I'd be interested in hearing other peoples' experiences.
> (1) Windows does loose matching on the case of filenames.  On one occasion
>     this has led to the filenames in the repository been "spontaneously"
>     changed.  The way this happened was (I think)
>     * On a Linux system, I did 'cvs remove NOTES.DOC', followed by
>       'cvs add Notes.doc', i.e., a 'safe' rename.
>     * On an NT system (using WinCVS 1.06), a user modifies NOTES.DOC (which
>       he still has checked out) and CVS apparently matches this with
>       Notes.doc in the repository and alters the repository name to
>       NOTES.doc when he checks this in.
>     * I do a 'cvs update' and am surprised to see NOTES.DOC resurrected.
>     It would seem that the Windows versions of CVS should try REALLY hard
>     not to do this.

It's possible that the Windows version of CVS doesn't know it is doing this.  
More likely, the AFS client/server is saying, "sure
I have NOTES.DOC!"  when Notes.doc is requested, then assumes that the user 
really wants to write "Notes.doc" for a write.  This
is a basic problem with UNIX file shares being used form Windows.

> (2) If the CVS repository is an AFS and if access to the repository is
>     granted by virtue of an AFS token in the name of address@hidden, this name
>     should be used in the log messages instead of the possibly random
>     Windows (or Unix) user name.  Lots of the Windows checkins are by
>     'Administrator' which is not very informative.

Sounds like you'd like to use ssh or pserver access.  How is CVS supposed to 
know this is what you wanted and not that you'd
granted every user access to the AFS repository as user 'cvsdev' and you really 
wanted the Windows user ID in the logs?

If you're really in the mood to hack, and you don't want to maintain this 
yourself, you might try and start a discussion with
some of the folks who know GSSAPI or who are currently doing security work on 

> (3) If an NT user checked out administrative files in $CVSROOT/CVSROOT,
>     modifies one of them and checks it back in the latest release in
>     CVSROOT carries DOS conventions.  When accessing the repository from
>     Linux, I then get
>       cvs log: syntax error in /afs/ 
> line '
> ' is missing '='
>     Either the Unix clients should care about foreign newline conventions
>     in $CVSROOT/CVSROOT/config, or the Windows clients should ensure that
>     these files have Unix newline conventions.

This is another common problem with network share access to a repository.  Any 
number of solutions have been proposed from the
CVS server "preserving" whatever line endings it finds to always using UNIX 
conventions.  Patches happily accepted.  Search the
list archives for more.

> (4) It's too bad that AFS's notion of machine-independent pathname doesn't
>     carry through to Windows.  Having to set up drive letter e.g., Z:
>     pointing to /afs/CELL/ breaks this notion and is so retro.  I'd like to
>     be able to use
>         :local:\\afs\CELL\common\cvs
>     instead of
>         :local:z:\common\cvs

Is this a Windows problem or a CVS problem?  If Windows, why are you telling 
me?  If CVS, have you tried converting back slashes
to forward slashes in your root specification?

> (5) Finally, we love to have network-level encryption of the data in AFS
>     files.  Is this on anyones radar screen?

Network level encrytion?  Shouldn't this be invisible to applications?


Derek Price                      CVS Solutions Architect ( )
mailto:address@hidden         CollabNet ( )
Take my advice, I don't use it anyway.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]