info-cvs
[Top][All Lists]
Advanced

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

Re: CVS_SERVER


From: Mark D. Baushke
Subject: Re: CVS_SERVER
Date: Wed, 01 Aug 2001 18:50:48 -0700

Hi Greg,

Summary: I understand your opinion, I do not share it. :-)

[Regarding the facts, I may have mis-remembered them concerning the
genesis of the CVS_SERVER environment variable. Greg could be correct
as I was under the impression it was part of the original rCVS patches
that were out around the time cvs 1.4A was released rather than the
stuff that got added to cvs 1.5...]

Greg and I don't appear to agree on very much and I suspect we will
never will see Greg acknowledge that another opinion other than his
own is useful or has any merit. I would like to be proved wrong about
this, but his recent postings to info-cvs leave me little hope that
it is true.

For what it is worth, I do believe that Greg's opinion has its
place. Any suggestion for enhancement/code-bloat needs one or more
critics to make sure that it is the best change possible. It is a
shame that he feels the need to try to cut a new idea off at the knees
before any kind of scope or problem-space definition can be
completed. I guess that must just be a matter of personal style.

For myself, I don't really care all that much about the specific issue
of CVS_SERVER configurations being stored in the checked-out tree or
in some other manner as that is not among the problems spaces I am
currently pursuing.

If someone comes up with an interesting patch to cvs, I hope it gets
both the criticism needed to make it better and the praise it deserves
to solving a problem.

Such a new feature may wish to consider handling general environment
variables used to control CVS behavior on a per-cvs-server basis.

Hmmm... speaking off the top of my head, perhaps something like a
~/.cvsrc extension that allows the transport (CVS_RSH) and remote
operations (the CVS_SERVER and potentially other environment variables
like CVSWRAPPER) might be interesting. 

Also, if something has to do the per-cvs-server book-keeping here, why
not consider an extensible mechanism. Even Greg's suggested wrapper
scripts should probably be more general purpose than specific to
control this kind of stuff for folks that are not that sophisticated
about how cvs works, but know that they need to use multiple
repositories that seem to have different requirements for use.

Enough for now. I don't need to keep this thread running any longer.
I'll let Greg (as per usual) have the last word and then it can die.

        Enjoy!
        -- Mark



reply via email to

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