info-cvs
[Top][All Lists]
Advanced

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

Re: doc on establishing pserver ...


From: Gerhard Sittig
Subject: Re: doc on establishing pserver ...
Date: Fri, 29 Jun 2001 20:17:07 +0200

On Thu, Jun 28, 2001 at 16:32 -0500, Daniel Beckham wrote:
> 
> It doesn't work as a daemon.  You either have to use it as a
> pserver with inetd (or whatever flavor of inetd) or you have to
> use rsh/ssh/etc to connect and execute the cvs command
> remotely.

That's absolutely OK for a tool which offers revision control
services. :)

> I think it's quite odd that it works like this, but I think the
> reasons are that cvs was never meant to serve remote requests.
> It was meant to be a local tool on a local filesystem.

How is this odd?  It's best UNIX tradition to reuse existing (and
most of all -- proven, stable, flexible!) functionality.  There's
no point in reinventing things anew.  Especially if it's not the
main purpose of your tool.  And because you will err for the
first few rounds of implementation.

Who does remember the latest questions like "Does CVS support
IPv6?", "Does CVS support PAM?", "Does CVS support ACLs?", and
"Does CVS support SSL?" ?  The obvious answer is always "Who
cares?".  Isn't that great?  CVS simply doesn't need to implement
any of these things.  And actually must never do it since other
tools can provide these supplemental services way better.  The
CVS user is free to plug in whatever fits best.  And the CVS code
remains lean or at least can concentrate on its real purpose.
Why would anybody want something else?  Don't confuse bloat with
features, please.

Sticking with the KISS principle, what's missing when you run CVS
as a user process on local files, talking to stdin and stdout in
a well specified protocol?  Nothing!  There are thousands of
tools available for network tunnels, encryption and compression,
user authenticaton and filesystem access control.  Hard coding
any of these things into CVS effectively reduces the user's
choice and flexibility.  While reinventing trimmed down
implementations for jobs where a general interface and better
tools are already available for is not really a good way to spend
one's time and resources.

> It just happens that rsh/ssh allow you to remotely execute any
> unix shell command in a remote fashion.  It's worked well like
> this forever and the designers have never felt the need to
> change this behavior.

For a very good reason.  They even should axe the inappropriate
stuff which is in CVS at the moment.


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" address@hidden
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.



reply via email to

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