From owner-cvs-all Wed Dec 2 20:08:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22741 for cvs-all-outgoing; Wed, 2 Dec 1998 20:08:45 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22733; Wed, 2 Dec 1998 20:08:43 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA29706; Wed, 2 Dec 1998 21:08:30 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA11254; Wed, 2 Dec 1998 21:08:29 -0700 Date: Wed, 2 Dec 1998 21:08:29 -0700 Message-Id: <199812030408.VAA11254@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Matthew Dillon Cc: Nate Williams , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: proposal: simple cvs mod to handle shared checked-out source trees In-Reply-To: <199812030251.SAA20835@apollo.backplane.com> References: <199812022200.OAA19221@apollo.backplane.com> <199812022209.PAA08774@mt.sri.com> <199812022258.OAA19488@apollo.backplane.com> <199812022303.QAA09143@mt.sri.com> <199812030251.SAA20835@apollo.backplane.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk [ adding -g to ignore the all mask ] > :Again, this is a very site-specific change that shouldn't go into > :FreeBSD, IMO. > > How is this a site specific change? It solves a nicely generalized > class of problems. A single class of problems that is specific to your site. I still don't see the need for it in any other site. You write: This way we not only have one copy of the checked out tree, but cvs commits also properly log which staff member modified the file last presuming that the staff member cvs commits the file after he has edited it. This is not the 'CVS' way of doing thing, and for the costs of a few bytes you are overly complicating things. > Huh? You mean 'not used by you', or you imply 'only used by me'. > This very situation has come up no less then three times at BEST and > has also come up to manage active data sets on another consulting job > I'm on unrelated to BEST called NextBus. There are obvious uses that > go beyond just me. I think that this sort of setup would be used by > more people if they knew it was possible. There are a huge number of > applications that it would work well with. The only win is saving a little bit of disk space. CVS is for 'concurrent' development of sources, not one big RCS tree. You could do the same thing with RCS if you chose not to use locks. CVS really isn't the solution, but RCS is. > :> In this case, cvs already does chmod munging when dealing with > :> the backend archive to handle shared CVS repositories. > : > :???? What do you mean by 'shared CVS repositories'? > > The standard way multiple users access a CVS repository these days, > now that rcs is no longer suid-root, is through shared group operations. Huh? How do you figure? > Another way of doing it is via a remote cvs account that everyone has > login permissions to, where shared group operations are not > required. This is the 'standard' way for multiple users accessing a CVS repository. On freefall the reason everyone belongs to the same group is a holdover from the original setup, not because it's anything special, or even required. > This can be secured more readily with a fake shell though I don't know > anyone who bothers. You do now. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message