From owner-cvs-all Wed Dec 2 14:59:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA16257 for cvs-all-outgoing; Wed, 2 Dec 1998 14:59:04 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA16232; Wed, 2 Dec 1998 14:59:02 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id OAA19488; Wed, 2 Dec 1998 14:58:46 -0800 (PST) (envelope-from dillon) Date: Wed, 2 Dec 1998 14:58:46 -0800 (PST) From: Matthew Dillon Message-Id: <199812022258.OAA19488@apollo.backplane.com> To: Nate Williams Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: proposal: simple cvs mod to handle shared checked-out source trees References: <199812022200.OAA19221@apollo.backplane.com> <199812022209.PAA08774@mt.sri.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :I do. It's a very site-specific change that can easily be worked around :by providing a wrapper for cvs for the shared folks. : :#!/bin/sh :umask 000 :/usr/local/bin/cvs : :The CVS program is complex enough already, and I'm 99.9% sure the CVS :maintainers would never accept a feature such as this when it's so easy :to work-around. : :Nate Well, I generally do not consider that sort of wrapper to be a reasonable permanent solution, especially in a multi-user environment. We have 20+ people who need modify-access to various company-wide configuration files. If I replace /usr/bin/cvs with a wrapper I screw up some of the traditional source projects (where we don't want relaxed group perms). If I put the wrapper somewhere else I have to make sure that everyone using it points their paths to it, which creates serious account maintainence issues. I use shell wrappers for relatively complex things, like getting JDK's to work or supporting multiple JDK revs on a single system (which you need to do if you want to write & test Java that is browser-compatible), but things are a whole lot more clean when a commonly used (or potentially commonly used) feature can be integrated into a program. In this case, cvs already does chmod munging when dealing with the backend archive to handle shared CVS repositories. This just extends it to the frontend to handle shared working data sets. I try to be forward-looking. While CVS/RCS has traditionally been used to manage source trees, I see their use in managing active system configurations more and more these days, including our own use of it. It would seem to be a useful feature so... -Matt Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message