From xemacs-m  Tue Jan 28 16:30:16 1997
Received: from atreides.mindspring.com (atreides.mindspring.com [204.180.142.236])
          by xemacs.org (8.8.4/8.8.4) with SMTP
	  id QAA27535 for <xemacs-beta@xemacs.org>; Tue, 28 Jan 1997 16:30:15 -0600 (CST)
Received: (qmail 18192 invoked by uid 52477); 28 Jan 1997 22:30:10 -0000
Sender: sj@atreides.mindspring.com
To: XEmacs beta <xemacs-beta@xemacs.org>
Subject: Re: source tree
References: <199701281610.LAA11489@nvwls.cc.purdue.edu> 	<m2pvyp21ux.fsf@altair.xemacs.org> 	<QQcalw29646.199701281714@crystal.WonderWorks.COM> <199701281720.LAA25532@xemacs.org>
Mime-Version: 1.0 (generated by tm-edit 7.100)
Content-Type: text/plain; charset=US-ASCII
From: Sudish Joseph <sudish@mindspring.com>
Date: 28 Jan 1997 17:30:10 -0500
In-Reply-To: Richard Cognot's message of Tue, 28 Jan 1997 18:17:44 +0100
Message-ID: <yviak9oxl9fx.fsf@atreides.mindspring.com>
Lines: 47
X-Mailer: Red Gnus v0.82/XEmacs 20.0

Richard Cognot writes:
>>>>>> "Kyle" == Kyle Jones <kyle_jones@wonderworks.com> writes:
Kyle> Gotta say that I hate the idea if it means beta testers can
Kyle> modify the source tree.  Having a central person or two like

> You can actually have a remote-cvs repository, which basically means
> that any beta-tester would be able to synchronize his source tree
> with the main tree, or perform diffs, but only the actual
> maintainers will be able to commit changes.

Yeah, this is what we use here at MindSpring, along with the FreeBSD
cvs acl stuff.  This is not difficult to setup, took me all of an hour
to copy FreeBSD's /CVSROOT, strip the stuff we didn't need, modify the
scripts to post commit messages to an internal newsgroup and add the
CVSROOT/avail acl scheme.  The end result is way cool.  I'd be glad to
help set this up if needed.


Under the FreeBSD scheme, only people named in CVSROOT/avail will be
able to commit.  The avail format also allows for ACL's at the
directory/file level.  So, you might allow Lars to commit to all of
TOP/lisp/gnus, but Wes might be restricted to just TOP/lisp/gnus/smiley.el.
(Uh, that's an example, I think Wes is a fine programmer, myself.)

Here's what a reject looks like to the person attempting the commit
(I'd ommited an entry in avail by mistake):

**** Access denied: Insufficient Karma(tlewis|doc/internal-page/documentation)
cvs server: Pre-commit check failed
cvs [server aborted]: correct above errors first!


Note that allowing world read-access is harder to administer than
restricting writes.  At MindSpring, we have the luxury of tcp-wrapping
access and we're behind a packet filter so we can do things like
having a well known account allowing read-only access via
authorized_keys, but that's not true of xemacs.org.  

I believe FreeBSD solves this by using cvsup servers and clients that
manage the actual generation and application of the patches--that way,
you do not need to allow shell access to the repository host for read
access.  I'm not certain if there aren't other things they do.

Write access is simpler--since you already trust the person to a
certain degree, granting a shell is not a problem (for us anyway).

-Sudish

