Home   News   People   Research   Funding   Publications   Presentations   Software   Blog   Wiki    Roles   Meeting   Deadlines   Summary   Server   Pictures

---

NCSU ASE - Group Server

 

• Web server 
• Using SVN
• CVS overview
• Setup CVS repository in the server
• Set CVS environment variables in the server
• Set up subdirectories in CVS repository in the server
• Using CVS in Eclipse in your desktop
• Use CVS command lines in your desktop
• Make CVS ignore certain resources with .cvsignore
• Running CodeSurfer

---

Web 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.

• How to disable directory browsing , APACHE  
  One of the "must do's" on setting a secure apache webserver environment is to disable directory browsing. As a default Apache will be compiled with this option enabled, but its always a good idea to get rid of this setting unless its really necessary. If you have some basic knowledge of vi editor follow this steps If you are on an RPM installation of Apache (which i dont really recommend) you will find the apache configuration file probably here: /etc/httpd/conf/httpd.conf. If you are using apache from the source tar balls ( like real men ) probably you will find the configuration file here: /usr/local/apache/conf/httpd.conf
  
  Using an editor like vi , edit the httpd.conf file and scroll until you find a line like this:
  
    Options All Indexes FollowSymLinks MultiViews
  
  To disable directory browsing carefully remove the line that says: Indexes and leave the line like this:
  
    Options All FollowSymLinks MultiViews
  
  Restart your apache webserver and thats it
• Set hostname. See here. Local copy
• Add group See here  
  
  groupadd aserg
• Add user See here   
  
  useradd -g aserg <username>  (aserg, aoprg)  
  
  passwd <username>

          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>

---

Using SVN

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 overview (adapted from here)

cvs - concurrent version system - can be used to easily accomplish several things:

• synchronize your data on multiple computers (such as in school and at home)
• work together with other people on the same project (such as journal paper)
• keep backup of your important data on group's server
• keep track of changes in your code or text

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:

• Archiving of source code and other files
  – You can restore previous versions of files (recover from accidental (or intentional) deletions and exploratory modifications to you files)
• Versioning of source code and other files
  – You can use the default versioning on specific files and add explicit version labels on groups of files
• Collaborative development
  – You can share project files with team members; changes can be made to the same file and the version control system will help you merge the differences

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.

---

Setting up cvs repository for a project (you can usually skip this step, because we have done this step)

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:

1. ask administrators (Evan Martin or Tao Xie currently)  to create a unix group (e.g., aserg) containing all people working on the project. See here for creating and maintaining a group
2. change permissions of your cvs repository:

  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

---

Set CVS environment variables in your account in the server  

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.

---

Setting up subdirectory for your tool/paper/doc in cvs repository

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

---

Using CVS in Eclipse (adapted from here)

Basic Version Control Concepts

A version control system typically has two parts. There is the versions control server and the clients. The version control server is accessed over a network – a local network or wide area network such as the Internet – by a version control client. The version control server manages access to the version control repository. Version control clients come in a variety of flavors: command line clients, window/gui clients, plug-in clients (for applications like Eclipse and file explorers).

Repository

This is where a copy of your files and directories are stored. Version control systems typically use some special file structure for tracking the differences between subsequent versions of a file.

 

Working Copy and Workspace

This is a copy of a file(s) (or project) in your local file system (not in the Repository). Workspaces map to Eclipe projects.

Project

Your files are grouped by project. Projects may have sub folders. A project is often a complete program; although, a project could be code for a software library or the XML/HTML files for documentation.

Commit

This is the process of saving files to the Repository. You may commit whole specific files or a whole project to the Repository.

Synchronize

This is the process of updating the local files on your computer with corresponding files in the repository.

CVS Clients

There are a variety of CVS clients: command line clients, windows clients (e.g. WinCVS), and plug-in clients like Tortise (plug-in for Windows Explorer) and the Eclipse CVS plug-in. This tutorial will address the Eclipse CVS plug-in. Note that the concepts carry over to other clients.

CVS and Eclipse

This tutorial assumes that you are familiar with Eclipse and have already created a project in Eclipse that you wish to version control.

Open CVS Perspective

There is an Eclipse perspective for CVS. You can enable this perspective from the Window menu:

Connecting to a CVS Repository

It is necessary to establish a connection with a CVS repository (the version control server). To do this:

 

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 

Updating: Before you start working you should always make sure you have the latest version of your code/paper as in CVS.

1. Right-click on your project in the package explorer and select Team->Update
2. Eclipse will download the newest version of the project and you will be ready to start programming or paper-writing.
 

Committing: When you decide to stop working you need to commit your changes to the repository so your colleagues can see them.

1. Right-click on your project in the package explorer pane and select Team->Commit
2. You are taken to a commit wizard.  Make sure to include a good message about what you changed/added and click Finish.

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.

 

References

Search google with "Eclipse CVS turtorial"

CVS--Concurrent Versions System

The official manual from http://www.cvshome.org

Open Source Development with CVS

by Karl Fogel and Moshe Bar
A free on-line book. Note that the commands are present in Unix/command-line terms and not from the point of view of Eclipse.

eclipse team cvs 2.1 faq

http://www.loria.fr/~molli/cvs/doc/cvs_1.html#SEC1

How to Synchronize With CVS from Eclipse

Introduction to CVS

Branching with Eclipse and CVS

---

Using CVS Client Commands in your local desktop

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.

Importing 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.

Day-to-day business

  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 and branching

Marking important versions

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"

Branching

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.

---

Make CVS ignore certain resources with .cvsignore 

You don't to add to CVS those unnecessary files such as *.pdf, *.tmp, *.ps (in cvsing LaTeX source files) and *.class, .classpath, .project (in both cvsing LaTeX source files and Java source files). Otherwise it will only bloat the CVS repositories unncessarily.

My usual way of dealing with these unncessary files are when you commit your files, a dialog will pop up, whose lower parts show which files are to be added and which files are to be changed. If this is the first time you add files, you can right-click these unnessary files,  and click "Add to .cvsignore". Then these fiels will never be added to the CVS.

But sometimes unfortunately you have added those unnecessary files into the CVS. Then you can click the file .cvsignore. Add lines of "*.pdf", "*.ps", .... into the .cvsignore. Then you right-click this .cvsignore "Team -> Commit". Then you can commit the new .cvsignore into the CVS. But I failed to exclude these unncessary files when I later commit them in the Eclipse. Of course, you can manually exclude these files in the view of the dialog that will pop up and whose lower parts show which files are to be added and which files are to be changed. If you find a better way of filtering out the already added files, let me know. More other details, see below.

Below are from here

Certain files/directories should never be merged into CVS. These include: .project, .classpath, other eclipse-specific settings for your local project;  and the build dir. In the Navigator view, you'll see some of these in the main project directory. To make CVS ignore these files, follow the steps below:

1. Select these files, right click to get the context menu. From the menu, select Team->Add to cvsignore.
   
2. You'll see that these items not longer show cvs info next to them in the explorer.
3. Select the project, right click, Team > Synchronize with Repository. Allow it to switch to the Team/CVS view. Verify you have no diffs with the repository.

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.

---

Running CodeSurfer

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

---

Home   News   People   Research   Funding   Publications   Presentations   Software   Blog   Wiki    Roles   Meeting   Deadlines   Summary   Server   Pictures