[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing CVS Command line.
From: |
Lummoxx |
Subject: |
Re: Changing CVS Command line. |
Date: |
Fri, 30 May 2008 11:34:18 -0400 |
> Um, DO WHAT?
> you are indicating that you(r company) had RH customize a kernel for a
> server destined for long service and the system configuration management at
> your company allowed both your company and RH to loose the change? It
> surprises me that RH did not deliver an src.rpm for the change as well as
> the binary version. (BTW have you asked RH if they still have THE change
> made?)
I know, neat, huh? I can't contact RH directly for it, since I'm not
associated with the corporate RH account, I have to go through our IS,
and that...isn't working. Luckily, this server is going to be in
production for only a few more hours, it'll be non-production long
before the gears of change turn far enough to make any headway on
this.
> And as for as building on the production machine, where is the clone that is
> a test machine? And sometimes things just have to be done.
We're migrating to a new server this weekend, so I've simply suspended
new projects on the old server for now. The test machine is still
running as a clone of the old server.
> Option A: don't use pserver,
The good news is, on the new server, only anonymous checkouts are
going to be using pserver. All authenticated access is via :ext:.
But most projects still allow anonymous checkouts, so I must be
prepared for thousands of projects being listed on the cvs command
line. The pserver risks have been evaluated, and the powers that be
accept them. I also expect a lot of inertia, and people continuing to
use CVS because they have been for years. I have to assume that my
number of CVS projects will continue to grow, and if not continue to
be a problem today, will again become a problem later down the road.
If that doesn't happen, great, but I can't count on it.
Hence, my request that a developer take pity on me, and do the voodoo
that they do, and add "--ar" as an alternative to "--allow-root" to
the main CVS package. That way I won't have to redo my hack every
time I upgrade CVS.
> Option B: reduce the number of roots you need to allow
We just provide the service. People are allowed to sign up, create a
project, and start developing. They manage their own projects, I just
provide the technical support to the server and software they use to
manage their projects.
> Option C: figure out what sourceforge/savannah did... they have lots of cvs
> roots and yet don't have this problem.
I've done some googling, but with migration to the new server 5.5
hours away...just no time.
Thanks,
Chris