[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS and AFS
CVS and AFS
Fri, 15 Jun 2001 05:58:29 -0400 (EDT)
[Sorry my previous send of this message got switch to base64 encdoing
becuase he body of the message contained a <return> character. Here it is
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.
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.
(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.
(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/sarnoff.com/common/cvs/CVSROOT/config:
line '^M' 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.
(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
(5) Finally, we love to have network-level encryption of the data in AFS
files. Is this on anyones radar screen?
Charles Karney Email: address@hidden
Sarnoff Corporation Phone: +1 609 734 2312
Princeton, NJ 08543-5300 Fax: +1 609 734 2586