Date: Wed, 2 Dec 1998 20:24:44 -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: <199812030424.UAA21145@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> <199812030408.VAA11254@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:> :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.
I don't understand this 'this is not the CVS way of doing things'
mantra you keep ringing up. I see no problem with it at all... perhaps
you are not willing to consider new ways of using old software, but
I sure am! To say that a program should not be extended to new
functionality because it wasn't originally written with that functionality
in mind is silly.
Secondly, we are not talking about the 'cost of a few bytes', and if you
had read my email more carefully you would understand that. We are
talking about a group of people who are working on an *ACTIVE* dataset.
Not personal copies of an archive, but a checked out working data set
that is being actively deployed by automated software running in the
background. I already outlined several examples showing the utility
of working things this way and I've already given ample counter-arguments
as to why this is preferable to individual copies (to reiterate: because
to modify the active system using individual copies requires a personal
checkout of the individual copy, a modification, a commit, and then
another checkout in the active dataset's working set. This is too
much baggage for the staff to be able to optimally work the dataset).
Thirdly, while not specifically stated in the past your assumption that
we are using this methodology on a small easily duplicateable dataset
is severely incorrect. The mix of data which is currently partially
covered by CVS approaches 8 gigabytes of which we've migrated just over
a gigabyte into CVS so far. It is not something appropriate for
20 different people to checkout individual copies of, especially with
the ever-changing nature of the active dataset being manipulated.
: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.
Again, you are making severely incorrect assumptions as to both the
mechanism the CVS option is supporting and the size of the dataset
in the particular application that I am using it on.
:CVS really isn't the solution, but RCS is.
Uh, no. RCS is what we were using before, and it caused no end of
trouble.
:> 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.
FreeFall uses a shared-group methodology, not a common-account
methodology. The CVS tree is stored in a special account but all
access to it is through a shared group. My CVSROOT environment
variable used to access the FreeFall repository access my local
account on FreeFall, not a common special account on FreeFall.
-Matt
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?199812030424.UAA21145>