Re: please check my newbie instructions for remote repository

[Todd Denniston]

Rusty Wright wrote:
> 
> I'm trying to help some coworkers start using cvs, and I'm a bit of a
> cvs newbie myself.  We have a host, canvas, which we use as our cvs
> repository.  If you have the time could you eyeball these instructions
> and point out any errors.  (And if you could send me an email letting
> me know that you've posted a followup, that would be really great.)
> 
> Thanks.
> 
> ================================================================
> 
> 1.  Edit your .login, .cshrc, .profile, or wherever you set your
> shell's environment variables and add the following lines:
> 
> For csh and its variants use
> 
>     setenv CVSROOT :ext:address@hidden:/home/MYNAME/cvs
>     setenv CVS_RSH ssh
>     setenv EDITOR /usr/bin/ex
> 
> For sh and its variants use
> 
>     CVSROOT=:ext:address@hidden:/home/MYNAME/cvs
>     export CVSROOT
>     CVS_RSH=ssh
>     export CVS_RSH
>     EDITOR=/bin/ex
>     export EDITOR
> 

If these repositories will be shared (more than one person checking in and
out of it). It is usually easier, especially if a person may move from one
project to another, to have a script to set these and other project specific
variables, and have each user just source the script for the project they
are on. 
example: in my setups, I have a script called Setup_Environment in a
CM_TOOLS directory for each project, it sets all the CVS variables and
modifies the PATH for project specific binaries, it also stores what the
path used to look like so if I run the Setup_Environment script of another
project, it can restore the original path and then modify it to the new
project.
This way if I want a user to change projects I just tell them to (under
bash) change their .profile to include the line

. /cm/proj/CM_TOOLS/Setup_Environment

and comment out any previous lines of that type.
this causes me much less headaches, especially when for hardware or policy
reasons the repository changes locations.

> Change both occurances of MYNAME to your login on canvas.  If you use a
> different editor, e.g., pico, change /bin/ex to the full pathname of
> your preferred editor; use "which pico" for example, to get its full
> pathname.
> 

Instead of indicating change MYNAME, you might try using either $LOGNAME or
$USER, so they don't have to edit anything.

> Make your current login session use these environment variables; e.g.,
> with csh "source" your .login, .cshrc, etc. file.  Or, even better,
> logout and login.  Run the command printenv, or for sh, set, to verify
> that these environment variables are in effect.
> 
> 2. Open an ssh window to canvas and mkdir cvs in your home directory.
> For example, with csh or bash you'd do
> 
>     mkdir ~/cvs
> 
> 3. Go back to back to the window for the development machine where
> you'll be working and issue the command
> 
>     cvs init
> 
> ====>>>
> ====>>> The above steps are once-only.  Thereafter follow the steps
> ====>>> below to add a new project (aka directory).
> ====>>>
> 
> 1. In the ssh window for canvas mkdir the project directory within
> the cvs directory.  For example, if your project directory on the
> development machine is named proj_dir then on canvas you'd do
> 
>     mkdir ~/cvs/proj_dir
> 
> Go back to your development machine's window.
> 
> 2. On the development machine go to the directory ABOVE the project
> directory and run the command
> 

Be careful with "directory ABOVE", I am not clear on what you mean.

>     cvs checkout -l proj_dir
> 
> where proj_dir is the project directory.  Then cd into the project
> directory on the development machine and run the command
>
>     cvs add *

They would need to copy (or create) their sources into the proj_dir before
being able to add them.

> 
> This will schedule adding all of the files in your project directory.
> It will ask for your canvas password so that it can verify things on
> that end.  You'll get a warning, "cvs add: cannot add special file
> `CVS'; skipping" which you can ignore.


If you really know they will get this message, I wonder do you really want
them all setting up a repository, or do you want them to share a repository
where they are modifying the same code base? 

Are they currently working on the same code base? If you just want them to
be somewhat isolated from each other while they work on their parts, but
will eventually want the code to be merged back together, using branches
with one $CVSROOT might be a better fit.  If you would like them to work in
one $CVSROOT you will need the admin of the machine to put all their
usernames in one group in the /etc/group file so the repository can be setup
for all group users to write to it. 
see the manual:
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_10.html#SEC82
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC13

> 
> 3. To really add (to the repository on canvas) the files from the
> development machine, in the project directory run the command
> 
>     cvs commit
> 
> This will prompt you for your password on canvas, then it will start
> your preferred editor so you can add a comment for this revision.
> Since this is the initial version, you can say something like "initial
> version".  When you save and quit the editor cvs will copy the files to
> your repository on canvas (the cvs directory in your home directory).
> 
< SNIP pretty much ok information >
> See http://www.cvshome.org for the full cvs documentation.
> 

Though having the main page in your document is good, for newbies it is
better to point directly to the manual page
https://www.cvshome.org/docs/manual/
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs.html
I also usually suggest that any user starting out with CVS read sections 1 2
& 3, along with my directions.

https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_1.html#SEC1
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC9
https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_3.html#SEC38

> !!!!>>>
> !!!!>>> WARNINGS
> !!!!>>>
> 
> Be extremely careful about doing anything to your cvs directory or any
> of its subdirectories on canvas.  

... with tools other than CVS.

> If you do anything to anything on
> canvas 

...under your $CVSROOT directory...

> after you have done the "cvs init" you will probably lose your
> files on the production and development machines the next time you run
> any cvs commands.  The cvs command will cheerfully and without any
> warnings or prompts remove your files.  While writing this and testing
> my steps, several times it removed my stuff.

BTW this is true of any version control system, doing things in the system
without telling the tool WILL most likely break things.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter