Todd Denniston wrote:
SUBRAMANIAN, SARAVANAN (SBCSI) wrote:
[...]
In the future, Please chop out any digest matterial that is
not related to
the new question.
Better still - and as I have asked Saravanan before - do not start a new
message by replying to an existing message. Many mail clients
- Original Message -
From: Jim.Hyslop [EMAIL PROTECTED]
To: 'Victor A. Prylipko' [EMAIL PROTECTED]; info-cvs@gnu.org
Sent: 28 2005 . 18:27
Subject: RE: how to make branch alias for HEAD branch
Victor A. Prylipko wrote:
I.m trying to make branch alias for HEAD branch using
cvs
Hey cool, you mind sharing that script? :)
As far as deleting the stored info, would it be safe
to delete via script run in loginfo, since by then,
the commit is already passed and verifymsg should not
be called anymore?
-chris
-Original Message-
From: Matt Doar [mailto:[EMAIL
Title: Remote repository permissions best practices
Ive hacked my way through setting up a few CVS repositories in the past, but Ive always struggled with getting the user/group ownership and file permissions correct. I always seem to end up with a setup where the users cant access the
Hi,
Well, I've had a crack at implementing the optimisation; and attached
is a patch which seems to work - but there is at least one nasty
hack in it; more about that in a sec.
To enable it you need to add:
TagOverwriteEnable=yes
to the config file in the CVSROOT; without that it should not
I followed this discussion only loosely and kept silent because I
suspect someone will shoot me to pieces for the complaint I'm about to
make, but now that we're to the stage of actual implementation, I
guess I'd like to say this anyway...
I have reservations about any system that makes
* Doug Lee ([EMAIL PROTECTED]) wrote:
I followed this discussion only loosely and kept silent because I
suspect someone will shoot me to pieces for the complaint I'm about to
make, but now that we're to the stage of actual implementation, I
guess I'd like to say this anyway...
Hey that's OK.
[top posting as a courtesy for Doug]
I haven't examined the patch, so I don't know how closely the implementation
matches the proposal, but if I understand the proposed changes, whitespace
is still insignificant, there's just more of it added as a buffer, as an
optimization to improve speed when
On Mon, Mar 28, 2005 at 02:12:56PM -0500, Jim.Hyslop wrote:
[top posting as a courtesy for Doug]
Thanks :) I just hope I don't cause a mess by that comment, which I
suppose was fuelled as much by lack of lunch as by anything. :-)
I haven't examined the patch, so I don't know how closely the
Howard, Les wrote:
I've hacked my way through setting up a few CVS repositories in the past,
but I've always struggled with getting the user/group ownership and file
permissions correct. I always seem to end up with a setup where the users
can't access the files that other users have
Todd Denniston wrote:
Howard, Les wrote:
I've hacked my way through setting up a few CVS repositories in the past,
but I've always struggled with getting the user/group ownership and file
permissions correct. I always seem to end up with a setup where the users
can't access the files
Title: Has anyone ever seen this?
This starting about 3 weeks ago (this server has been running for over two years).
background:
This is a pserver configuration on a dell rack mount two processor machine, currently
running redhat 8. It has 12gigs of ram. Was using cvs.1.11.15 but just
[top posting as a courtesy for Doug]
-R Recursively change permissions of directories and
their contents.
Its the their contents part that is the problem, you only need and want to
change the ownership and permissions on the directories.
The files should be read only, and we
Todd Denniston wrote:
1) all the users who need write access to the repository
should be in the
same UNIX group.
Doesn't this effectively negate any benefit of using groups? For example, in
our setup we want full-time staff to have general access to most of the
repository, and co-op students
Jim.Hyslop wrote:
Todd Denniston wrote:
1) all the users who need write access to the repository
should be in the
same UNIX group.
Doesn't this effectively negate any benefit of using groups? For example, in
our setup we want full-time staff to have general access to most of the
15 matches
Mail list logo
