All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: Mike Touloumtzis <miket@bluemug.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BK PATCH 1/4] fix NGROUPS hard limit (resend)
Date: Tue, 22 Oct 2002 15:13:41 -0500	[thread overview]
Message-ID: <200210221513.41729.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <20021022194512.GA18955@bluemug.com>

On Tuesday 22 October 2002 02:45 pm, Mike Touloumtzis wrote:
> On Tue, Oct 22, 2002 at 01:03:47PM -0500, Jesse Pollard wrote:
> > And I really doubt that anybody has 10000 unique groups (or even
> > close to that) running under any system. The center I'm at has
> > some of the largest UNIX systems ever made, and there are only
> > about 600 unique groups over the entire center. The largest number
> > of groups a user can be in is 32. And nobody even comes close.
>
> Large CVS hosting operations like GNU Savannah have historically used
> patches to increase NGROUPS.  Using one group per project in CVS is the
> sanest way to manage a big repository with complex permissions.

OK, I'll bite..

Why is this?

I saw the post about having to have access to a lock directory by a
cvsuser, but how is that different than having that directory with an
ACL entry that includes the cvsuser? Or an ACL that includes the
group that the cvsuser is a member of?

Granted, each project repository would have such a directory for
locks belonging to the project, but that seems to already be the
case. Setting up the ACL would just be one additional step in
setting up a project.

-- 
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

  reply	other threads:[~2002-10-22 20:10 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-22  0:36 [BK PATCH 1/4] fix NGROUPS hard limit (resend) Timothy Hockin
2002-10-22  1:39 ` Aaron Lehmann
2002-10-22 17:44   ` Tim Hockin
2002-10-22  9:51 ` Alan Cox
2002-10-22 17:26   ` Tim Hockin
2002-10-22 17:45     ` Alan Cox
2002-10-22 17:37       ` Tim Hockin
2002-10-22 18:03         ` Jesse Pollard
2002-10-22 18:21           ` Tim Hockin
2002-10-22 18:54             ` Rik van Riel
2002-10-22 19:12             ` Jesse Pollard
2002-10-22 19:39               ` Rik van Riel
2002-10-25  9:34             ` Panu Matilainen
2002-10-25 12:49               ` jw schultz
2002-10-25 18:17                 ` Tim Hockin
2002-10-22 19:45           ` Mike Touloumtzis
2002-10-22 20:13             ` Jesse Pollard [this message]
2002-10-22 20:30               ` Mike Touloumtzis
2002-10-23 14:17                 ` Jesse Pollard
2002-10-22 20:18           ` Hildo.Biersma
2002-10-23  2:41           ` Simon Kirby
     [not found] <354127220@toto.iv>
2002-10-23  0:09 ` Peter Chubb
  -- strict thread matches above, loose matches on Subject: below --
2002-10-23 10:16 Randal, Phil
2002-10-29 19:32 Timothy Hockin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200210221513.41729.pollard@admin.navo.hpc.mil \
    --to=pollard@admin.navo.hpc.mil \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miket@bluemug.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.