Solved

Network-based RCS

Posted on 1997-06-10
3
385 Views
Last Modified: 2013-12-26
When I was at Oracle, we hade a modified version of RCS which we called NETRCS. It basically worked the same as RCS, except we could set an environment variable to point to the hostname and path of the repository:

(NETRCS=hostname:/dir1/dir2/dir3 ; export NETRCS)

Obviously, we had had serveral NETRCS servers, each having sources for different projects.

Does anyone know where I might find something similar? Someone pointed me to CVS - unfortunately that didn't do what I needed.

Thanks
0
Comment
Question by:drwagner061097
  • 2
3 Comments
 
LVL 1

Accepted Solution

by:
linas earned 50 total points
ID: 1293382
What is it that CVS didn't do for you?  CVS is built on top of
RCS, and it adds networking and a very nice multi-user model, and is wildly configurable to to oodles of stuff.  I am concerned that if CVS is not good enough, nothing will be. RCS, is, after all, a pretty crude, clunky tool ...

If you got the bucks, I recommend IBM's CMVC, although it will
probably cost you more than your computer did.
0
 

Author Comment

by:drwagner061097
ID: 1293383
I've been told by 2 people that CVS is the package I need. I've downloaded v1.3, and in neither of the man pages (cvs.1 and cvs.5) could I find the terms "remote host", "network", or any indication that I can use the "hostname:/pathname1/pathname2" convention when specifying directories. Am I missing something? Can someone give me an example to the following scenario?:

hostA has an RCS (or CVS) repository.
hostB also has an RCS (or CVS) repository.
I'm working on hostC and want to checkout a file(s) on hostA.
Now I want to checkout a file(s) on hostB.

If you like, make it simpler and omit hostB from the above scenario - I just want to checkout a file from a remote host without using NFS. I'm told CVS is the answer - perhaps I still have an old version, but v1.3 was the latest I could find.

Thanks!

- David Wagner

0
 
LVL 1

Expert Comment

by:linas
ID: 1293384
The current official version is 1.9 so 1.3 is very very old.
Of course, I should have provided urls:http://www.loria.fr/~molli/cvs/doc/cvs_toc.html
http://www.loria.fr/~molli/cvs-index.html
http://www.cyclic.com/tkcvs/

CVS does define it's own wire client-server protocol,
which is what you are looking for.  You have to dig around
a bit in the documentation to figure out how to set this up;
I vaguely remeber doing setenv CVSROOT some.machine.com:pserver:/hoem/cvsroot and also having a file
called .cvspasswd which contains a pasword . I use the "pserver"
style of authentication. Everything is so automatic I gforgot how its done

I extract some random paragraphs out of random sections of
the documentation:
Notes on the Current Implementation
***********************************

   The client is built in to the normal `cvs' program, triggered by a
`CVSROOT' variable containing a colon, for example
`cygnus.com:/rel/cvsfiles'.

   The client stores what is stored in checked-out directories
(including `CVS').  The way these are stored is totally compatible with
standard CVS.  The server requires no storage other than the repository,
which also is totally compatible with standard CVS.

   The server is started by `cvs server'.  There is no particularly
compelling reason for this rather than making it a separate program
which shares a lot of sources with cvs.

   The server can also be started by `cvs kserver', in which case it
does an initial Kerberos authentication on stdin.  If the authentication
succeeds, it subsequently runs identically to `cvs server'.
   The current server implementation can use up huge amounts of memory
when transmitting a lot of data over a slow link (i.e. the network is
slower than the server can generate the data).  There is some
experimental code (see `SERVER_FLOWCONTROL' in options.h) which should
help significantly.

How to Connect to and Authenticate Oneself to the CVS server
************************************************************

   Connection and authentication occurs before the CVS protocol itself
is started.  There are several ways to connect.

rsh
     If the client has a way to execute commands on the server, and
     provide input to the commands and output from them, then it can
     connect that way.  This could be the usual rsh (port 514)
     protocol, Kerberos rsh, SSH, or any similar mechanism.  The client
     may allow the user to specify the name of the server program; the
     default is `cvs'.  It is invoked with one argument, `server'.
     Once it invokes the server, the client proceeds to start the cvs
     protocol.

kserver
     The kerberized server listens on a port (in the current
     implementation, by having inetd call "cvs kserver") which defaults
     to 1999.  The client connects, sends the usual kerberos

     authentication information, and then starts the cvs protocol.
     Note: port 1999 is officially registered for another use, and in
     any event one cannot register more than one port for CVS, so the
     kerberized client and server should be changed to use port 2401
     (see below), and send a different string in place of `BEGIN AUTH
     REQUEST' to identify the authentication method in use.  However,
     noone has yet gotten around to implementing this.

pserver
     The password authenticated server listens on a port (in the current
     implementation, by having inetd call "cvs pserver") which defaults
     to 2401 (this port is officially registered).  The client
     connects, sends the string `BEGIN AUTH REQUEST', a linefeed, the
     cvs root, a linefeed, the username, a linefeed, the password
     trivially encoded (see scramble.c in the cvs sources), a linefeed,
     the string `END AUTH REQUEST', and a linefeed.  The server
     responds with `I LOVE YOU' and a linefeed if the authentication is
     successful or `I HATE YOU' and a linefeed if the authentication
     fails.  After receiving `I LOVE YOU', the client proceeds with the
     cvs protocol.  If the client wishes to merely authenticate without
     starting the cvs protocol, the procedure is the same, except     `BEGIN AUTH REQUEST' is replaced with `BEGIN VERIFICATION
     REQUEST', `END AUTH REQUEST' is replaced with `END VERIFICATION
     REQUEST', and upon receipt of `I LOVE YOU' the connection is
     closed rather than continuing.


0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Expand LInux Boot partition remotly 3 78
Perl Awk Need Help 3 94
Thin secure Windows 10 5 48
Not needed 13 54
Introduction: Dialogs (2) modeless dialog and a worker thread.  Handling data shared between threads.  Recursive functions. Continuing from the tenth article about sudoku.   Last article we worked with a modal dialog to help maintain informat…
Have you tried to learn about Unicode, UTF-8, and multibyte text encoding and all the articles are just too "academic" or too technical? This article aims to make the whole topic easy for just about anyone to understand.
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
This video explains how to create simple products associated to Magento configurable product and offers fast way of their generation with Store Manager for Magento tool.

707 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now