Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 2 Dec 1998 21:08:29 -0700
From:      Nate Williams <nate@mt.sri.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Nate Williams <nate@mt.sri.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: proposal: simple cvs mod to handle shared checked-out source trees
Message-ID:  <199812030408.VAA11254@mt.sri.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
[ 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812030408.VAA11254>