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 09:52:43 -0700

> From: address@hidden (Greg A. Woods)
> Date: Wed,  1 Aug 2001 01:49:48 -0400 (EDT)
> 
> [ On Tuesday, July 31, 2001 at 21:39:47 (-0700), Mike Castle wrote: ]
> > Subject: Re: CVS_SERVER
> >
> > On Wed, Aug 01, 2001 at 03:47:31PM +1200, Chris Cameron wrote:
> > > For various reasons beyond my control, I'm accessing cvs servers
> > > that need different CVS_SERVER values.  Has anyone implemented
> > > or considered a patch to add the CVS_SERVER information to the
> > > CVS directory (like Root and Repository) so that one can go to
> > > different checked out areas and do updates, commits etc. without
> > > having to change CVS_SERVER?
> 
> Huh?  CVS does that now.  I access dozens and dozens of different
> servers on an almost daily basis and I've never changed anything after
> I've done the initial checkout!

That would seem to indicate that you are not able to reproduce the
conditions that Chris Cameron is observing in the wild rather than
that cvs does not have a potential environment variable book keeping
problem.

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.

For example, I have heard of systems out there where /usr/local/bin
has multiple versions of cvs and they have their version number
assigned as a part the the command name and /usr/local/bin/cvs-1.10
and /usr/local/bin/cvs-1.11.1 are NOT found unless you set CVS_SERVER
to 'cvs-1.11.1' ... If you have ONE system you need to use that is
that badly configured, you probably do NOT want to inflict that on all
of the other repositories you need where the administrator has called
the cvs executable by its 'cvs' name.

In these conditions, I can see where it might be useful to cache the
correct values of CVS_RSH and CVS_SERVER with the tree that was
checked out.

> Here's one I just checked out moments ago:
> 
>       $ cat CVS/Root        
>       :pserver:address@hidden:/source

And that signifies absoultly nothing about the 'cvs' command that
needed to be run on the remote site. It says that the administrator
put what you need into the inetd.conf (or xinetd.conf) file for you so
YOU don't have to set CVS_SERVER yourself or remember to set it later.

Using :pserver: is useful, but not everyone uses that particular
protocol to get to remote cvs servers.

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.

Try setting CVS_SERVER to some other command (like 'blah') and then
using the trace option

    cvs -t -d address@hidden:/path/to/repos status

and you should see 

    ssh address@hidden blah server

which means that CVS_SERVER is trying to be run on the remote server
site of the RSH or SSH connection to somehost.com

If someone has an ancient 'cvs' executable that would be found first
in your path (and on a remote cvs server you may not have the control
over your path that you really want), it might even be useful to
specify a full pathname to a more recent cvs executable (presuming
that you are not able to set your PATH on the remote system). That the
full pathname will only work for a single CVSROOT may be true.

I have even seen CVS_SERVER variables need to do something like:

setenv CVS_SERVER "env LD_LIBRARY_PATH=/usr/local/lib:/lib cvs"

because the libz shared library was not in the LD_LIBRARY_PATH that
was used by default by the system.

> > Saving CVS_RSH would be nice too  :->
> 
> That's a bit trickier.....  :-)

Yes, it is trickier, but it is not that difficult to do.

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.

If someone wants to provide more environment variables that should be
preserved as well as other tokens (like the cvs user varaibles for the
'cvs -s VAR=VAL cmd') to be passed on the cvs commands, I see no
fundamental reason for it not to be done.

Come up with a patch for review. For example, it might be useful if
the CVSWRAPPERS environment variable could be varied by repository
too. You may also want to have a supression mechanism similar to
CVS_IGNORE_REMOTE_ROOT.

Good luck.

> It's also something that you should be able to change without
> invalidating your working dirctories.  Personally I almost always just
> use SSH (for non-annonymous read-only repos like above, that is), so
> I've never found any reason to change it.  I certainly wouldn't want to
> accept non-SSH access to anyone's remote repo, and I don't mind using
> SSH on my private network either....  It could probably even be argued
> that the default should be "ssh".

Actually, the default CVS_RSH *is* ssh on the FreeBSD version of cvs.

        Enjoy!
        -- Mark



reply via email to

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