Automated Software Engineering Research Group Server 
Automated Software Engineering Research Group Server
The upload directory is at /var/www/html and a group member's homepage is a subdirectory whose name is the same as the user name in the server.
gpasswd -a <username> emacs
or usermod -G <comma separated group list> <username>
groups <username>
remove a member from a group: editing the /etc/group
delete a user: userdel <username>
delete a user and its home dir: userdel -r <username>
Here is some info on using SVN in our server. Here is a tutorial on using Subclipse, a plugin for Eclipse.
A repository root is one of the following:
svn+ssh://ase.csc.ncsu.edu/svn/root/papers
svn+ssh://ase.csc.ncsu.edu/svn/root/toolsrc
svn+ssh://ase.csc.ncsu.edu/svn/root/docs
svn+ssh://ase.csc.ncsu.edu/svn/root/slides
For more info, check out SVN book.
To import your CVS project or any project stored in local directory to SVN, you can do the following in Eclipse's resource view
1. Disconnect a project by Team-> Disconnect (if it has already been previously sotred and connected to CVS)
2. Import a project to SVN by Team-> Share Project (follow the step-by-step screen)
Server common commands:
Create a repository
$ svnadmin create /path/to/repos
$ # Create an FSFS-backed repository
$ svnadmin create --fs-type fsfs /path/to/repos
# Create a Berkeley-DB-backed repository
$ svnadmin create --fs-type bdb /path/to/repos
$
cvs - concurrent version system - can be used to easily accomplish several things:
Though cvs setup can be very complex, below we give couple of simple examples how to use cvs to accomplish these things.
CVS overview: cvs stores copies of your files and history information in a special directory called repository. To work on the files, you checkout a copy of the repository to a separate directory. When you are done, you commit your changes (i.e. store the new versions of the files to the repository). You and your collaborators can have multiple checked out copies of the repository (even on different computers) and work in parallel. You can update a copy to reflect recent changes submitted to the repository. cvs has some support for merging independent changes done by various people at the same time, though human intervention is usually needed in such cases. cvs also allows you to compare versions, checkout older version of the repository, create multiple branches of the project, and so on.
We will be using the Concurrent Version System (CVS) in our research group as a mechanism for sharing resources (e.g. tool source code and papers). It is a tool that can be used for many types of other collaborative development, such as writing documentation.
There are a number of reasons to use a version control system:
Version control is a process by which you can keep a recorded history of the changes to your files (e.g. software source/code). A version control system, such as the Concurrent Version System (CVS), is an system that helps you accomplish version control of your files.
A version control system is useful for a number of reasons, the most important is to keep a historical record of the various versions of files you are developing. Should you accidentally delete a file or a portion of a file that you are working on, you can recover the most recent version, or any version, of that file. Of course, you must periodically commit (a.k.a. "checked-in") your files to the version control system for this process work. A version control system is typically used by software development teams as a mechanism for sharing the development of the various files in a project.
Additional overviews of CVS can be found in the references section below.
Also read Chang Liu's CVS tips.
When starting a project (e.g. a paper), you first need to setup a cvs repository. To do that, you create a directory where you want to keep the repository (such as /cvs/root/ on ase server) and run the following command:
cvs -d /cvs/root init
You want to keep the directory somewhere out of your sight (it will be accessed only by cvs system, not you); you may also want to keep all your repositories together at a single location (such as /cvs/root/) to make backups easier.
If you want to share your repository with other people, you need to:
chgrp -R aserg /cvs/root
chmod -R g+w /cvs/root
chmod g+s /cvs/root
chmod g+s /cvs/root/CVSROOT
To view permissions, see info here.
Automatic email notification of CVS changes
Two important variables to set in your server account before you start are CVS_RSH and CVSEDITOR. CVS_RSH determines the remote shell to be used, CVSEDITOR determines the editor to use when entering comments about versions. My settings are in my .bashrc as follows:
export CVS_RSH=ssh
export CVSEDITOR="emacs -nw"
You can SSH to the server and go to your home directory. Modify the .bashrc file in your home directory by adding the above two lines.
Finally, create a "module" inside your new cvs repository; for example as follows:
mkdir /cvs/root/toolsrc
You can also create a subdirectory under toolsrc as follows:
mkdir /cvs/root/toolsrc/mytool
There is an Eclipse perspective for CVS. You can enable this perspective from the Window menu:
ase.csc.ncsu.educvsroot
directory/folder (in our server as "/cvs/root"). extssh from the
drop-down list.Figure: Add CVS Repository Dialog
After validation, CVS Repositories window in Eclipse will show the connected repository. Note that you can have multiple repositories.
Figure: CVS Repositories
5. You can browse the existing subdirectories in the CVS from there. Note that you are suggested to create these initially empty subdirectories for your tool/paper as described in here if they don't exist.
When you see the subdirectory you want to check out, click it and click right mouse button -> "Check out As"
A dialog pops up. Check the radio of "Check out as a project in the workspace". Click "Next".
You can specify the local hard drive location where you want to put the local working copy. Click "Next"
Click "Finish."
Then you can copy files or create new files in this location.
When you are done, you can switch the resource perspective, click the project that you check out from the CVS, do the one of the following tasks for interacting with CVS
Committing: When you decide to stop working you need to commit your changes to the repository so your colleagues can see them.
Sometimes multiple people will be working on a project from different locations at the same time. If this situation occurs and someone changes the repository version before you commit there could be conflicts. If this happens you will be shown a "diff" (a comparison between 2 versions of a file) showing the differences between your version and the repository version. Eclipse makes it very easy to choose which version you would like to commit. If you aren't sure whether to keep your code or your colleagues you can always cancel the commit and discuss the issues with your colleagues before committing. Don't worry if you make a mistake or commit the wrong code because with CVS you can always go back to a previous version. More functionality is available in the Eclipse "Synchronizing" perspective, accessible by right clicking on the project in the package explorer and choosing Team->Synchronize from the menu.
Now we need to checkout a working copy (if you are sharing the repository, all of your colleagues must do this as well; you can also check out multiple copies such as in school and at home):
If you are working on toolsrc:
cvs -d /cvs/root checkout toolsrc
or from elsewhere:
cvs -d :ext:youruserid@ase.ncsu.edu:$HOME/cvs/projectname checkout toolsrc
This will create a directory toolsrc at your current location; inside there will be a directory CVS containing some internal data.
To import your data to CVS repository, copy all the files to be imported to the newly created directory, change to the directory and run:
cvs add filename (for every file you want to add; including in subdirectories)
cvs add directory (for every directory you want to add)
(Wildcards in filenames and directory names are allowed). Then run:
cvs commit .
After some dialog, the files you selected are committed to the repository.
cvs update . - run this command before changing anything in your
local copy; it will check the repository for any
changes
cvs add filename - add a new file to the repository
cvs remove -f filename - remove a file from the repository
cvs commit . - commit changes to the repository; run it after
you have finished changes (i.e. when leaving school
and going home)
cvs status . - display status of the files in the repository.
Files not managed by cvs will be listed with a
questionmark at the beginning
cvs --help command - give a detailed help on the command
Tagging is used to mark a particular version of file or repository. You want to use it for example for marking exact version of the text document that you have submitted to a journal or conference.
cvs tag cpm-submission . - mark all files with tag "cpm-submission"
cvs -d /cvs/root checkout -r cpm-submission project
- checkout a copy of the repository marked with
the tag "cpm-submission"
Here is an example where you may want to use branching. You finished a draft version of article, which you would later want to extent to a long journal version. Now you want to submit to a conference and you need to cut the long version to fit the page limit for the conference submission.
Before you start cutting, you want branch the conference version from the main stream.
cvs tag -b cpm-submission .
Now there are two versions: HEAD (which is still the one checkout in the current directory) and cpm-submission. To edit the cpm-submission version, you need to checkout a new copy:
cvs -d /cvs/root checkout -r cpm-submission -d projectname-cpm projectname
This will create a new directory projectname-cpm with the branch. If you did everything correctly, cvs status command should show so called "sticky tag cpm-submission" associated with the files in the new directory.
Both versions (HEAD in projectname and cpm-submission in projectname-cpm) can now be edited separately. (Changes can be later merged between branches; this is, however, outside of scope of this document.)
You can setup ssh not to ask for your password. Here is a relevant portion of man ssh:
The public key method is similar to RSA authentication described in the
previous section and allows the RSA or DSA algorithm to be used: The
client uses his private key, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to
sign the session identifier and sends the result to the server. The
server checks whether the matching public key is listed in
$HOME/.ssh/authorized_keys and grants access if both the key is found and
the signature is correct. The session identifier is derived from a
shared Diffie-Hellman value and is only known to the client and the
server.
If you are committing source code, also ignore .classpath and .project. See JavaGu(i)(y): Stop adding Eclipse .classpath and .project files to ...FAQ What is the function of the .cvsignore file? from here
To exclude
resources from management under CVS version control, a .cvsignore file
can be placed in the parent folder of a resource. Each folder has to
specify its own .cvsignore
file as there is no logic for path-relative resource specification. The
Navigator has UI support for CVS exclusion in its context menu for any
resource in a project. Follow Team > Add to .cvsignore
to the dialog that allows selection based on the name of the resource,
a wildcard, or a custom pattern to match multiple resources. The .cvsignore file is not an Eclipse invention. Its
syntax is defined by CVS, and the Eclipse team plug-ins simply pass the
file on to CVS when sharing a project.
First add the following two lines to your .bashrc
export PATH=$PATH:.:/usr/tools/codesurfer-1.9p5/bin
export LM_LICENSE_FILE=/usr/tools/codesurfer-1.9p5/bin/license.dat
Before you run the tool, you need first start the licensemanger by running the following command line:
license-manager start
Then follow the instruction at:
/usr/tools/codesurfer-1.9p5/doc/codesurfer/Tutorial/GettingStarted.html