--a1QUDc0q7S3U7/Jg
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 17, 2003 at 02:03:40PM -0500, Frederick Bruckman wrote:
> No. (I use "rsync", so I have to remember to set RSYNC_RSH=3Dssh.)
> Enough of my problems...

When I read this, I thought maybe you caught the dry humor I
intended. But considering later statements, maybe not. In either
case, good point. :^>

> The initial checkout is likely to be slow, granted, but for the
> updates, the Internet is not the issue. "cvs" works its magic by
> transferring the cost of bit-moving over the network, to heavier disk
> i/o and cpu work on the hosts. With a PIII/500 dual MP, UW-LVD SCSI
> disk, 28.8 connection, it takes something like *15m* to update the
> whole NetBSD "src" tree.

Okay, I mispoke in referencing the Internet. But it doesn't matter
*how* many changes you have to make, adding encryption and
decryption overhead at the ends (where you've *already* put the diff
and I/O overhead to save on the network bandwidth) will *always* be
slower than not doing so, and it's really unnecessary in what I see
as the general case of CVS usage.

> Well, OK. Some people still use "rsh". I'll grant you, it may even be
> a reasonable choice in your particular case, since the costs of "ssh",
> made bearable by faster cpus, rise again with greater bandwidth. But
> now that you've so eloquently established that only a moron would have
> trouble setting an environment variable, what's the big deal?

Because, as things stand now, everybody who doesn't know doesn't set
anything (and complains when rshd isn't enabled ;^>), everybody who
wants ssh sets $CVS_RSH, and (I'm speculating here, but so have you
been) at least some of the people who want to use rsh don't bother
setting $CVS_RSH. I'm also speculating that the two groups who know
what they want also know what $CVS_RSH does. So, I think, if you
go change it in the default environment, they'll recognize what
changed... but if you go change the default behavior of a well-known
application, they're more likely to be confused no matter how much
noise you make about it at the time.

> Or more to the point, why is it so hard to build consensus here
> on the tiniest thing?

Sheesh. It's not like I have commit rights or am going to bitch
(at least not publicly) if cvs(1) behavior changes. But Itojun
*asked* for opinions. I have one. My apologies!

> > 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.
> you speak for unequivocally, "against". In fact, since you now hold
> the quorum, we should probably just ask you first before doing
> anything.

Um... I'm a little unclear on what I did to deserve that response.
You said "does anyone use rsh any more?" I (and, I'll note, several
others) said, "Um, yes, actually we do." Now, just because it wasn't
the answer you wanted or thought you were going to get doesn't give
you the right to misrepresent my intentions.

> to represent? There are greater than one hundred NetBSD developers
> scattered all over the world, using "ssh" to connect to the main cvs
> server (over the Internet), vs. ???.

And NetBSD should be used only to develop NetBSD? Is that really the
prevailing sentiment?

??? represents, to me, using NetBSD in a standard, corporate,
production environment. I don't right now. I wish I could, but my
employer is a bit more difficult to convince than some. But, unless
I'm mistaken, there *are* some people around here doing just that.

> Frankly because, that would inconvenience me, as opposed to you. I
> guess I was being selfish.

How would that inconvenience you? Unless you're explicitly
overwriting the $CVS_RSH shell variable, in which case you'll still
get what you asked for, having a default for the shell come from the
system will get exactly the same effect without requiring that
patches be applied with each new import of CVS sources.

--=20
gabriel rosenkoetter
gr@eclipsed.net

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (NetBSD)

iD8DBQE+73Sk9ehacAz5CRoRAhPUAJ9Khbhev2yTkSx2B2fMzKXNhonMiACbB6Pd
QTIruihk3zdb0jPcqyExwyo=
=R/0a
-----END PGP SIGNATURE-----

--a1QUDc0q7S3U7/Jg--