Subject: Re: CVS_RSH to ssh
To: None <>
From: gabriel rosenkoetter <>
List: tech-userlevel
Date: 06/17/2003 13:03:08
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


If you really must change this (please don't, see below), why would
you change it in imported source rather than simply adding it to our
shell skeleton scripts or /etc/{profile,csh.schrc}?


On Tue, Jun 17, 2003 at 08:11:23AM -0500, Frederick Bruckman wrote:
> I think it's a good idea. On every new system I install, "cvs" fails
> mysteriously until I remember to set CVS_RSH=3Dssh. Who uses "rsh"
> nowadays, anyway? ("pserver" !=3D "rsh")

C'mon... you don't have a tarball of your default shell environment
that you dump on any new machine?

You don't NFS mount your home directory within a given network?

Realisitically, do you *really* go in and *manually* set CVS_RSH
every time you set up a new machine? Why?

On Tue, Jun 17, 2003 at 11:03:53AM +0100, David Brownlee wrote:
> 	Most people tend to use cvs over ssh nowdays - particularly
> 	anyone dealing with the NetBSD source tree (pkgsrc included).

I believe that that's factually incorrect. Most NetBSD developers
MIGHT tend to do cvs *commits* over ssh nowadays, but I can't
imagine that anyone in their right mind would be doing a large
checkout or an update over ssh, especially not over the really-real
Internet. (If it's packet insertion you're worried about, you do the
large, actually-transfer-data co or update with rsh/pserver, then
immediately do an update with CVS_RSH=3Dssh to make sure that nothing
differs locally from the server.)

I use rsh over a private gigabit network with CVS all the time. It
could be said that I should just use pserver instead, but rsh works
without adding yet another daemon to the server side, and my trusted
network really can be trusted to be private (it's not just private
address space, it's physically detached from any other network). I
really doubt I'm alone in a corporate environment.

I also doubt that ANY company would keep their CVS server in a
globally addressable space. Why would you? That's what a VPN is for.

On Tue, Jun 17, 2003 at 11:33:07AM +0000, Geoff Wing wrote:
> 3) segregated networks may use rsh (maybe libwrap'ed rsh) but they're also
>  more likely to delay or fully compensate for changes in base utilities

I think you're mistaken about that. I think having systems on a
private network precisely means that you don't have to worry as much
about changes in base utilities, only in those applications you
always care about.

For instance, I always do the "install everything" option in Red Hat
Linux at work, secure in the knowledge that I know, personally,
every single person who can touch the network it's attached to.
Getting the, "Why isn't bc(1) installed?" question is pretty
irritating. If I now have to start answering the "Why doesn't CVS
work unless I set CVS_RSH to the obvious value?" question... then
I'll NEVER be able to replace Red Hat with NetBSD.

> I'm suspect (without validation) that itojun's idea is that point 3 is so
> rare that those people are fully taken care of and that anyone else can
> cope with such a change (which conforms with most common practice (I thin=

Speaking as a sysadmin in a corporate environment that uses cvs over
rsh, this would really piss me off. (That's all speculation in a
void, of course, because it's basically impossible to use NetBSD as
anything but my workstation here anyhow...)

On Tue, Jun 17, 2003 at 11:10:50AM -0500, Frederick Bruckman wrote:
> Yes. ;-) Now answer this: does anyone honestly use cvs over rsh
> anymore?

Yes. All of my developers do on a daily basis.

> The code changes involved are tiny.

So why not do them in our default environment rather than in
imported code?

> other projects are likely to follow our lead, and the cvs people,
> too, eventually.

Along those lines, why don't we just adopt Subversion? I'm sure some
other projects would follow our lead, and I understand the CVS
people in fact *want* that to happen.

(Please don't take that as a troll. Let's not have a source
versioning software argument. It was intended rhetorically.)

gabriel rosenkoetter

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.2 (NetBSD)