Contents
1 - My Sourceforge account.
2 - Becoming an EMC developer.
3 - Becoming a SSH client.
4 - Downloading ssh.
5 - Setting up ssh
6 - Sourceforge checkout.
7 - Making a change to the sourceforge repository.
Info quote - adding files
8 - Periodic update of your copy.
The development version of EMC exists on sourceforge.com so I needed to get a free user account there. Soon after I asked for an account, I received an email with a url for my final sourceforge setup. I had to enable cookies on my browser while I do this and must allow them anytime while I'm using the sourceforge service.
2 - Becoming an EMC developer.
As soon as I got that far, I emailed Will my login name so that he could set me up as a developer. He did that and after a few minutes (hours) I was listed. Then the first thing I did was trash my developer status by a wrong click. (Sorry for the second request Will) After a bit I was a developer again. So the next thing I tried was a secure login and there I was.
Hint Now it seems that there is a problem with ssl and some browsers so you should read the log in page carefully if you use that other browser.
The secure login got me to my personal page. From there I searched
for EMC and selected the correct one. I added messages and news and
thought I was all set. I went back to my personal page and saw those
added things. But when I went to the cvs repository for EMC, I was
immediately lost in deep stuff. Searching around sourceforge
for information was very little help!
The first question I had was how do you send the commands listed on the sourceforge cvs page. My thought was that perhaps, with the secure login, sourceforge had somehow taken over my computer so I started a virtual terminal and just typed in the stuff listed there. I got back a complaint so I read that documentation again.
SourceForge CVS DocumentationSince the complaint was something about ssh, I started reading and found out that I needed something called SSH. A quick check of my system revealed that I had no commands called ssh, no files named ssh, and no package around that said anything about ssh.For all developer (read/write) access, you will be using SSH. SSH (1.x)
client must be available to your local machine. The local environment
variable CVS_RSH must also be set to the path to ssh. This is done on most
linux (bash) systems by typing:export CVS_RSH=ssh
Anonymous CVS access uses CVS pserver and does not require SSH.
If you get 'permission denied' errors with no prompt for a password, you do
not have this environment variable set properly or SSH is not available to
your system. Fix this before suspecting a password problem.
My fall back plan is an altavista search where I came up with this link .
http://www.ssh.org/Reading there comfused me because it says very little about USING the thing that they call a secure terminal. I did learn that ssh is some sort of secure terminal that can be used to identify me and allow me to do work on a remote computer as a "trusted" user. (little do they know)
A little more altavista turned up a site that provides very good links to the whole world of ssh.
http://www.heimhardt.de/htdocs/ssh.htmlBlessings on this fellow because he has provided a bunch of links and a bunch of info. (much of it I did not understand, and I do not understand it yet)
From the site above, I found a binary download for Linux 2.2.* and untarred
it at the root directory. It installed several files in the /usr/local/bin
directory. I considered that progress, because now when I entered
the command ssh, I got a pile of options on the screen. Still a bit
lost I went back to the web site above.
From the heimhardt.de site, I found this site:
http://www.tac.nyc.ny.us/~kim/ssh/which provides a very good introduction to what setting ssh up on your system is about.
So I followed the instructions given for setting up a public key and
copied it into the file that allows remote access to my machine.
This is a very mysterious process but it did provide the files that they
said it should.
I know from what little concurrent version system work that I'd done around home that in order to participate fully with it I would need a current version of the repository on my computer.
I returned to the cryptic documentation on sourceforge. I started this process by a secure login using my netscape browser because it doesn't have a problem with ssl. Then from my personal page at sourceforge I clicked on the EMC project near the bottom of the page.
Hint. If you answer their questionaire, it will be reduced to a small block and the entire page will fit on a single screen.
The sourceforge document says:
How to check out source via SSHThis did not turn out quite like I expected because what's obvious to them is still muddy to me. I got the -dloginname part okay. My name at sourceforge is rayhenry so that gets substituted right after the (-d). I got some further clues from the cvs page itself so I started my virtual terminal again (konsole) and made sure I was using bash by just typing in bash. Then I entered the line:Type the following, making necessary obvious substitutions for your username
and project.cvs
-dloginname@cvs.yourproject.sourceforge.net:/cvsroot/yourproject co
directoryname
export CVS_RSH=ssh
and I was back to my prompt. Then I entered the next line but the obvious substitution of directoryname took a couple of tries because it is lowercase.
cvs -z3 -drayhenry@cvs.EMC.sourceforge.net:/cvsroot/EMC co emc
after a bit, sourceforge asked for my password. Wow! Now I'm getting somewhere.
This checked out the entire structure and files of the emc part of the
NIST system onto my machine. So I did it again for the rcslib directory
and after a half hour my hard drive held a copy of the sourceforge repository.
7 - Making a change to the sourceforge repository.
So there it is. The connection has been made. The download is complete. I am a developer. Now I need to learn a little bit about using CVS lest I trash the entire repository and look to all the world like the idiot that my close friends already know me to be.
You may work on those files with your favorite text editor and save changes. One thing that I found out is that sometimes my editor leaves backup and invisible files laying around after I close it. Another thing that I've noticed is some cases where a comparison between versions of a file will show differences between Microsoft end-of-line versus unix end-of-line characters. Or just putting a space in a line will cause diff to think that the line has been edited. So I'll need to be a little careful with these kinds of editing problems so that others can see the real differences that I've made to a file.
Okay now that I've made changes that will add a feature that all of us want, I need to update the repository at soureforge with the revised file and any new files and directories.
The sourceforge documentations says:
After initial checkout, you can change into this directory and execute cvsI am going to do this by following the commands that Will sent me that are intended to commit some of my Tcl/Tk work to the repository and make these changes a part of the next release of EMC. First I'll copy my email to Will that describes what I've done.
commands without the -d tag. For example: cvs update
cvs commit -m "comments for this commit"
cvs add myfile.c
> I've been working with running scripts from a variable menu under
> tkemc. For this I used a sub directory called emc/scripts. I see that
> you already have a scripts directory in the release that contains a lot of
> the emc setup files.
>
> I'd like to see these tcl scripts implemented as a part of the release.
> What do you recommend that we do for a directory name for these kinds of
> things.
Will responded
>Currently only developers see the scripts directory. When we build aI suggested that we expand on this just a bit with:
>distribution the script files for the appropriate platfrom are
>moved to the top level directory before the distribution is built.
>But end-users will probably not want the tcl scripts in the top
>level directory.>Perhaps instead of using emc/scripts we could put it in a directory
>emc/tcl or emc/tclscripts.
emc/tcl/libsince this would allow us to expand the tcl based stuff without adding much clutter to the main emc directory. Then all I had to do to my genedit and tkemc files was change the directory reference in the scripts menu setup code.
emc/tcl/scripts
Will responded with the following set of commands to use after the ssl log in and the bash shell in konsole.
export CVS_RSH=sshHe also suggested that I edit the file emc/scripts/emc.inc and add the new directories because, "That way the files would automatically be added the next time we build a distribution." (Will)
cd emc
mkdir tcl
cvs add tcl
cd tcl
mkdir lib scripts
cvs add lib scripts
cd scripts
cvs add * ( Copy all your scripts here. )
cd ../../scripts/<PLAT> (edit the emc.inc file to add emc/tcl/lib & scripts)
cd ../..
cvs commit
I got hung up somewhere in the cvs commit command. Sourceforge
kept insisting that my files had been added but I couldn't see them when
I looked in the emc/tcl/scripts directory. After a bit of reading
of the cvs documentation I found this
helpful page.
To add a new file to a directory, follow these steps.I had successfully added the files to the repository but I had not successfully committed them. What I did was commit each file with the following set of commands. After I submitted each command, it asked me for my sourceforge password. (makes me wish I hadn't made every other letter a capital)* You must have a working copy of the directory. Getting the source.
* Create the new file inside your working copy of the directory.
* Use `cvs add FILENAME' to tell CVS that you want to version
control the file. If the file contains binary data, specify `-kb'
(Binary files.).* Use `cvs commit FILENAME' to actually check in the file into the
repository. Other developers cannot see the file until you
perform this step.You can also use the `add' command to add a new directory.
Unlike most other commands, the `add' command is not recursive. You
cannot even type `cvs add foo/bar'! Instead, you have to$ cd foo
$ cvs add bar- Command: cvs add [`-k' kflag] [`-m' message] files ...
Schedule FILES to be added to the repository. The files or
directories specified with `add' must already exist in the current
directory.The added files are not placed in the source repository until you
use `commit' to make the change permanent...The `-m' option specifies a description for the file. This
description appears in the history log (if it is enabled). It will also be
saved in the version history inside the repository when the file is committed.For example, the following commands add the file `backend.c' to the
repository:$ cvs add backend.c
$ cvs commit -m "Early version. Not yet compilable." backend.c "
export CVS_RSH=sshBut I forgot that I edited and added a copy of emc/scripts/emc.inc so I will have to commit that one as well or it will not be visible.
cd emc/tcl/scripts
cvs commit -m "tkemc parport show script" IO_Show.tcl
cvs commit -m "tkemc script" MDI_Input.tcl
cvs commit -m "Experimental tkemc script" Subroutine.tcl
cvs commit -m "genedit gcode script" feedrate.ncw
cvs commit -m "genedit gcode script" gohome.ncw
cd ../../src/emctask
cvs commit -m "added script menu" genedit.tcl
cvs commit -m "tkemc popup" tkbackplot.tcl
8 - Periodic update of your copy.
You will also want to periodically update your local set of files with any changes that others have made to the sourceforge repostory. You can do this with three basic commands. Update, checkout, and remove.
Update works to compare each of the files in your local repository with the same file in the sourceforge repository. Any changes that have been made there will be updated on your local copy. Checkout is required for any new files or directories that have been added to the sourceforge set. Ocasionally you will need to use checkout to get the latest new files. Remove is used to delete files from the repository. If you have files on your system that no longer exist in the sourceforge set you will get a warning message when you update.
Update
This does not require a complete download. The Sourceforge version
of CVS will figure out for you what files have been changed from the versions
that you have and will update those on your hard drive.
update--Bring work tree in sync with repositoryWhile update is working, it will give you a list of the files that it looks at and will report any changes, conflicts, etc. The following info page describes that report.* update [-AdflPpR] [-d] [-r tag|-D date] files...
* Requires: repository, working directory.
* Changes: working directory.
After you've run checkout to create your private copy of source from
the common repository, other developers will continue changing the
central source. From time to time, when it is convenient in your
development process, you can use the `update' command from within your
working directory to reconcile your work with any revisions applied to
the source repository since your last checkout or update.
update outputCheckout`update' and `checkout' keep you informed of their progress by
printing a line for each file, preceded by one character indicating the
status of the file:`U FILE'
The file was brought up to date with respect to the repository.
This is done for any file that exists in the repository but not in
your source, and for files that you haven't changed but are not
the most recent versions available in the repository.`P FILE'
Like `U', but the CVS server sends a patch instead of an entire
file. These two things accomplish the same thing.`A FILE'
The file has been added to your private copy of the sources, and
will be added to the source repository when you run `commit' on
the file. This is a reminder to you that the file needs to be
committed.`R FILE'
The file has been removed from your private copy of the sources,
and will be removed from the source repository when you run
`commit' on the file. This is a reminder to you that the file
needs to be committed.`M FILE'
The file is modified in your working directory.`M' can indicate one of two states for a file you're working on:
either there were no modifications to the same file in the
repository, so that your file remains as you last saw it; or there
were modifications in the repository as well as in your copy, but
they were merged successfully, without conflict, in your working
directory.CVS will print some messages if it merges your work, and a backup
copy of your working file (as it looked before you ran `update')
will be made. The exact name of that file is printed while
`update' runs.`C FILE'
A conflict was detected while trying to merge your changes to FILE
with changes from the source repository. FILE (the copy in your
working directory) is now the result of attempting to merge the
two revisions; an unmodified copy of your file is also in your
working directory, with the name `.#FILE.REVISION' where REVISION
is the revision that your modified file started from. Resolve the
conflict as described in Conflicts example. (Note that
some systems automatically purge files that begin with `.#' if
they have not been accessed for a few days. If you intend to keep
a copy of your original file, it is a very good idea to rename
it.) Under VMS, the file name starts with `__' rather than `.#'.`? FILE'
FILE is in your working directory, but does not correspond to
anything in the source repository, and is not in the list of files
for CVS to ignore (see the description of the `-I' option, and
cvsignore.).
When you have a working repository on your computer, checkout will compare your files with the sourceforge files and will download any new or revised files. You can run the command - cvs checkout emc - and it will update all of the emc files. I had to use the longer version to checkout all of the rcslib files.
cvs -z3 -drayhenry@cvs.EMC.sourceforge.net:/cvsroot/EMC co rcslib
Remove
The remove command is used to take files out of the repository. Normally I will not use this command at all because most of the files are not mine. But ocasionally a file gets removed from the repository and I want to remove my local copy. Fortunately I can do this by just removing them from my local set and they will no longer be considered when updating. Since they have been removed from sourceforge they will not show up on the next checkout either.
If you want to remove some of your files from the sourceforge set, the
following page tells how to do that.
Directories change. New files are added, and old files disappear.
Still, you want to be able to retrieve an exact copy of old releases.Here is what you can do to remove a file, but remain able to
retrieve old revisions:* Make sure that you have not made any uncommitted modifications to
the file. Viewing differences, for one way to do that.
You can also use the `status' or `update' command. If you remove
the file without committing your changes, you will of course not
be able to retrieve the file as it was immediately before you
deleted it.* Remove the file from your working copy of the directory. You can
for instance use `rm'.* Use `cvs remove FILENAME' to tell CVS that you really want to
delete the file.* Use `cvs commit FILENAME' to actually perform the removal of the
file from the repository.When you commit the removal of the file, CVS records the fact that
the file no longer exists. It is possible for a file to exist on only
some branches and not on others, or to re-add another file with the same
name later. CVS will correctly create or not create the file, based on
the `-r' and `-D' options specified to `checkout' or `update'.- Command: cvs remove [options] files ...
Schedule file(s) to be removed from the repository (files which
have not already been removed from the working directory are not
processed). This command does not actually remove the file from
the repository until you commit the removal. For a full list of
options, see Invoking CVS.Here is an example of removing several files:
$ cd test
$ rm *.c
$ cvs remove
cvs remove: Removing .
cvs remove: scheduling a.c for removal
cvs remove: scheduling b.c for removal
cvs remove: use 'cvs commit' to remove these files permanently
$ cvs ci -m "Removed unneeded files"
cvs commit: Examining .
cvs commit: Committing .
This page is a part of the EMC Handbook. It was written by Ray
Henry and is distributed under the GPLD license. If you have
comments, criticisms, suggestions, or editing you are welcome to submit
them to the author. You are also welcome to edit this page
directly as a contributor on openavenue.com.