[Top][All Lists]

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


From: Mark D. Baushke
Subject: Re: CVS_SERVER
Date: Wed, 01 Aug 2001 15:09:13 -0700

> From: address@hidden (Greg A. Woods)
> Date: Wed,  1 Aug 2001 15:58:29 -0400 (EDT)
> [ On Wednesday, August 1, 2001 at 09:52:43 (-0700), Mark D. Baushke wrote: ]
> > Subject: Re: CVS_SERVER 
> >
> > Not all administrators will install access to the cvs server via
> > :pserver: and therefore they require that the users use ssh or rsh to
> > get into the box then don't have the cvs you want installed in the way
> > you like it.
> Not all the repositories I access regularly are anonymous read-only
> repositories (i.e. ones using the so-called cvspserver protocol) either.

Good for you. However, I have used :pserver: protocol repositories
with read-write permissions in some cases. Calling them read-only is
doing the :pserver: protocol an injustice.

> > To review, the CVS_SERVER environment varible is there to contain the
> > name of the 'cvs' command to use on the remote system after initiating
> > the connection to that remote system via CVS_RSH typically with the
> > :ext: method rather than the :pserver: method.
> Well, that use of CVS_SERVER is a cheap hack to work around incorrectly
> installed servers.  Propogating that hack into the state of the working
> directory is an extremely bad idea.

You are mistaken.

 1) The default CVS_SERVER value is either 'cvs' or argv[0] depending
    on how the ARGV0_NOT_PROGRAM_NAME macro is defined in main.c
    The names are sometimes different if the client and server are
    heterogeneous machines with regard to hardware and/or operating
    systems (eg, UNIX client and VMS server).

 2) The CVS_SERVER is not a 'cheap hack' as it was developed because
    all the world is not UNIX with UNIX semantics as to command
    execution aliases via remote access shells. [No matter how much
    you want cvs to be a unix only solution, it does work on a large
    number of platforms.]

    It is my recollection that the CVS_SERVER was introduced to make
    it possible to work on machines which did not or could use a the
    same command name on the client as is used on the server.  That it
    also turned out to be useful to debug new versions of cvs for Greg
    A. Woods is a nice example of writing useful functionality in a
    general manner so that even Greg can abuse the system in ways that
    were not originally intended. (1/2 :-)

 3) Just because you appear to only ever use unix boxes does not mean
    that other systems out there do not exist that sometimes need to
    have the name be 'CVS' or 'cvs.exe' on the client and something
    else on the server (possibly even a full pathname using odd
    characters like brackets when that pathname is a VMS-style path
    with lots of $s and square brackets in the path).

Greg, I know it may be difficult for you, but could try not to show
your UNIX-centric bigotry in every e-mail you send in the future.

> (The most valid uses of CVS_SERVER are only to assist in testing
> multiple versions of CVS on the same machine -- it's not something users
> should ever have to set in normal use!)
Had you said that CVS_SERVER_SLEEP was only intended to debug cvs,
then I would have agreed with you...

It certainly appears that you have strong opinions about how 'users'
should do their work 'normally'.  Why does it bother you so much that
folks use the full set of features that are availabe with cvs?

If you only desire to use CVS_SERVER to assist in testing, good for you.

It is also about the only mechanism to get the cvs user variables (you
know, stuff you can pass with 'cvs -s foo=bar') passed to the remote
server side correctly... or such has been my understanding. I'd love
to hear about any gimmicks to work around that if you know them.

For example, it would be nice to pass 'cvs -s DEFECTID=12345 commit'
and have the commit_prep script see if the bug database has a 12345
defect number assigned to the user trying to do the commit. Instead,
you need to hack the verifymsg script to look for 12345 in a log
message to fail the commit at a very late stage indeed. If you don't
set DEFECTID, then the commit may fail because the cvs trigger is not
friendly to cvs user variables... Oh well, that is another topic for a
later day...

> If people have this problem regularly, and yet are having problems
> getting the CVS install corrected on the server, then a very very very
> simple little wrapper script can be used to pre-set things like
> CVS_SERVER and CVS_RSH for them.  That wrapper script can even live on
> the server so long as they're using ":ext:" with SSH (or RSH, etc.).

Why do you assume that the people with the problems that need to use
CVS_SERVER or CVS_RSH have any control or home directories or anything
on the remote cvs server? 

It may not be possible for them to setup anything on the remote
end. Just because the administrators of some system are being
pig-headed does not mean that the community of cvs developers need to
make it hard for people to use cvs.

> > Before I hacked cvs 1.3 to have root.c so that it could store the
> > correct repository information in CVS/Root you needed to either
> > specify the repository on the command line or via the CVSROOT
> > environement variable.
> I'm still not convinced that hack was a totally good thing even though I
> make use of it constantly myself.....  In the end its often more of a
> pain than a solution when things about the remote server change
> (eg. it's name, access methods, authentication tokens, etc.).  A proper
> wrapper script would make fixing the pain trivial and a one-time affair
> no matter how many working directories you might have checked out.

Then I suggest that YOU use a wrapper script if that makes life so
much better for YOU. However, you may find yourself needing to use
CVS_SERVER yourself if you do that and you want the remote end to run
your wrapper script instead of the 'cvs' that it finds first in its
path... maybe you will be lucky and can put your own version of 'cvs'
into your path on all of the remote servers that need it. You may have
trouble if your systems admin restricts your remote command execution
to only the one 'true' cvs executable.

In any case, you might want to look back at my original implementation
of root.c. If a user explicitly forced a 'cvs -d cvs-spec' it would
trash all the existing data in the CVS/Root file and replace it with
the information on the -d option. Later users choose to replace this
capability with one that will just ignore the CVS/Root contents by
setting an environment variable. I'm not sure this is a better way for
a user to use the tool or not, but at least it is flexible enough for
most folks to use cvs.

> I do still agree that there's a bit of a Catch-22 situation where people
> can get themselves into really big trouble if they accidentally point to
> a copy of a repository (instead of the one true repo).  The one major
> benefit of storing that info into CVS/Root is that it's almost
> impossible for the client user to make such mistakes any more.  However
> whether the pain is worth the gain in a general sense is not necessarily
> so obvious.

I am of the school that believes that making a flexible tool is more
useful than making one that is to restricted to be used in the wild.

Your remarks lead me to believe you are of the other school of there
being only one true way to design and implement anything. I guess we
are always going to disagree on that one.

> You want to put as little as possible irrelevenat information about the
> server into the working directory.  "Hard-coding" more irrelevant stuff
> is just a recipe for causing confusion and furstration when that
> information must be changed.

It is to avoid 'hard-coding' the use of the string 'cvs' that
CVS_SERVER exists. Flexiblity is a good thing.

> > Actually, the default CVS_RSH *is* ssh on the FreeBSD version of cvs.
> Yeah!  :-)  One down!

Wow, we agree on something. Amazing. :-)

        -- Mark

reply via email to

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