[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch: Add support for CVS_USER environment variable

From: Mark D. Baushke
Subject: Re: Patch: Add support for CVS_USER environment variable
Date: Sat, 06 Mar 2004 10:30:36 -0800

Hash: SHA1

M.E. O'Neill <oneill@cs.hmc.edu> writes:

> You wrote:
> > And with no real understanding of how the patch you have provided is
> > intended to be use or may be tested, how is it useful to add your
> > code  to the network release? [...] Nor am I convinced that the
> > patch itself  is inherently useful without a better understanding of
> > how sites other  than yours are to use this patch.
> I did provide a link to where I found the patch floating on the net, at
>       http://www-jcsu.jesus.cam.ac.uk/jcn/documentation/cvs/
> cvs_trusted_tech.html

Thank you for the link.

I did not see such a link in your 'patch' message:


which was posted to the bug-cvs list on Wed, 25 Feb 2004 15:41:34 -0800.

If it was in a subsequent e-mail message, I missed it.
> which describes a system almost identical in concept to the one I was
> developing.  It says far better than I can in email why you might want
> this.   (And I don't think an approach using pserver is exactly
> equivalent.)

Which is probably okay as I think the :pserver: system is ill-advised
for anything other than anonymous read access. (This view is not
universal, so it seems unlikely that support for :pserver: will be

I'll have to read more closely about TrustedCVS when I have more time.

> > Your patch to subr.c tells cvs to read the CVS_USER environment
> > variable and do commits as that user instead of as the user LOGNAME.
> BTW, your use of LOGNAME makes it look like you're talking about an
> environment variable.  RCS did pay attention to such an environment
> variable, and back when CVS was based on RCS, CVS may have done too.
> But today, it's pretty much the name from getpwent or nothing.

Sorry, I was writing at the end of my day as well (2:10am). My
recollection of your patch was that it was happening in getcaller()
which will spend some time if the real rood uid is "root" to try the
LOGNAME USER or getlogin() or if getlogin() and getpwuid() both fail,
return the uid as a string.

> >> I'd deleted my copy of the CVS sources before I sent my patches.
> >> I'm  done.
> >
> > Fine. Thanks for the suggestion. It is a pity you didn't want to
> > help  out more, but not everyone has the time to do such.
> It really does come down to time.  I'm writing this message at 3am
> when  I should be sleeping.  If it's still not fixed in June, and
> people  still care, I'll have some time.  But during the semester,
> things are  pretty crazy for me.

Yes, my present schedule has left almost no time to do anything but plow
thru the e-mail for cvs rather than to try to do any development or
testing myself. I have considered adding a few patches to the mix, but
when they are not fully formed, I just don't have the extra time to
finish them right now myself.

>      M.E.O.
> P.S.  I've been struck several times by the fact that the amount of
> time we've all spent emailing about these two tiny patches could have
> been spent doing the remaining grunt work to make them "proper"
> patches, probably several times over.   I guess we all lose there.

Could be. However, I can answer a lot of e-mail even when I don't feel
alert enough to be committing patches into the system.

> P.P.S.  I've found in use that my -q patch misses a case somehow,
> leading to occasional unwanted output showing up.  I think it's linked
> to committing files added with cvs add.

Indeed, I suspected there were a few such holes in the logic which is
why I suggested the desire for a script that did a full range of testing
for the various kinds of cvs commit operations with -q and -Q active.

        -- Mark
Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]