Russ Allbery wrote: > > Chris Cowan <[EMAIL PROTECTED]> writes: > > > - AFS (unlike DFS) does not support any sort file locking in the > > "normal" (POSIX) manner. Even if you enable the "k" ACL on the > > directory! > > Irrelevant for CVS, which uses dot-locking that works fine in AFS. > Well call me skeptical, but have you actually stressed this in a variety of situations or are you just basically working with a small group of well behaved developers (very little merging and conflicts), from your own machine (the one cache manager case)? Have you included cases where multiple users attempt to commit the same module, from different machines (and thus multiple cache managers)? I can visualize a number of scenarios where things may not go totally smoothly. (Suppose I lose Network connectivity during a commit? Do I have to get multiple people to flush cache managers in order to guarantee a successful commit?) Sorry, but I've been bitten by the non-POSIX filesystem semantics of AFS enough times in the past, that I would want to thoroughly test this. (or know that someone else had first.) > > - It is not trivial to properly set up AFS ACLs so that you get the > > correct permissions and access by all parties using the CVS repository. > > It may not be possible! > > It's trivial. Give everyone who needs to commit to a tree "write" access > to all directories in that tree, give everyone "read" access to CVSROOT, > and create a subdirectory of CVSROOT (I call it logs), give everyone > "write" access to it, move the history and val-tags files into it, and > symlink to the files. I disagree. It's trivial for an AFS admin, not necessarily a general user. > > > - Many users of AFS get very confused by the difference between RO and > > RW volumes. Typically, this is done with mount points. This is usually > > differentiated by using /afs/.iil instead of /afs/ill. I would be > > absolutely sure that your CVS repository does not sit in any replicated > > volumes. If so, make sure you're accessing the RW copy. > > Don't replicate your CVS repository, other than the top-level mount point > volume if you use that sort of scheme. You should in general never > replicate development trees; replication is for mostly static data that > needs to always be available. Well nowhere in the original post did the author identify himself as an AFS Admin or a general user. I assumed that he might be the later. If that's the case, the decision has been made for him. > > > Bottom line, I would follow the advice of the other person that replied. > > Use CVS in client/server mode or use a remote filesystem that can handle > > the POSIX functionality upon which CVS depends, like DFS or NFS (w/ the > > lock manager). > > I couldn't disagree more strongly; that's horrible advice. CVS works > great on AFS. I'm really recommending pserver. There it's unambiguous. Works as documented and intended, and I don't have to explain nearly as much to somebody else. I can use just about any old Wintel box for the task. Given the price of 20GB IDE drive these days, I find very little incentive for using any remote filesystem in this scenario. If I had AFS available, I would archive my repository to it via Cron.
begin:vcard n:Cowan;Chris tel;cell:512-970-7294 tel;fax:707-988-8744 tel;work:512-329-5646 x1306 x-mozilla-html:FALSE url:http://www.2nd-wave.com org:2nd Wave, Inc. version:2.1 email;internet:[EMAIL PROTECTED] title:Development Manager adr;quoted-printable:;;1515 Capital of Texas Highway South=0D=0A=0D=0ASuite 400A;Austin;TX;78746; note;quoted-printable:Tivoli Certified Enterprise Consultant=0D=0A end:vcard
