Date: Wed, 2 Dec 1998 18:51:55 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Nate Williams <nate@mt.sri.com> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: proposal: simple cvs mod to handle shared checked-out source trees Message-ID: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
:How is any different than having a 'different' cvs binary?
:
:> 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).
:
:Ok, write a wrapper that checks for -g, and then have it relax the
:permissions.
:
: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.
:
:Commonly used at your site, but very rarely (if at all) used at other
:sites. The 'CVS' way of doing thing is to have each developer check out
:their own copy of things, not to have a shared repository.
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.
:> 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.
This is nothing more then an obvious extension to that paradigm.
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 can be secured more readily with a fake shell though I don't know
anyone who bothers.
-Matt
:Nate
:
:
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812030251.SAA20835>