server

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

You are suggested to use free SmartSVN as an easy-to-use SVN client.

To access a SVN repo, you need to install a Git client. For Windows users, one strongly recommended tool SVN client tool is TortoiseSVN, which has nice integration with your Windows Explorer.

If you are using Windows, you must configure your system variables to add a new system variable "SVN_EDITOR" and assign an editor tool such as "notepad.exe" as the value to this system variable. Such configuration is needed when when make "svn commit" without a text message after it.

Here is some info on using SVN in our server. Here is a tutorial on using Subclipse, a plugin for Eclipse.

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

Below are contents copied from "Subversion – A Summary Cheat Sheet – Learn svn in 10 minutes" http://jwamicha.wordpress.com/2008/05/29/subversion-a-summary-cheat-sheet-learn-svn-in-10-minutes/

===

This post is a summary of the subversion book, only that the summary takes you straight in. Please find the subversion book here:

http://svnbook.red-bean.com/

If you have not done so already, begin by installing Subversion on your system. For Fedora/CentOS/Redhat users, this is explained in another post here:

http://jwamicha.wordpress.com/2008/04/25/quick-svn-trac-installation-on-centosfedora/

SUBVERSION COMMANDS SUMMARY

1.) Checkout the code and do an update in case of any changes made since your last update (We assume that you are using apache dav server to access your code and not svnserve):

$svn checkout http://192.168.0.54/svn/repos/server_code server_code

If your repository requires authentication:

$svn checkout –username my_usernamehttp://192.168.0.54/svn/repos/server_code server_code

Update your working copy:

$svn update

(update from current)

$svn update -r BASE server_code

(update foo from base revision)

$svn update -r 1200 server_code (update foo from revision number 1200)

2.) Make changes:

$svn add eg svn add new_directory

(add a new directory foo)

$svn delete

$svn copy directory1 directory2

(copy directory directory1 to directory2)

$svn move directory2 renamed_directory

(rename?)

3.) Examine your changes (Can be done even with no network access to the subversion repository):

$svn status

(To get an overview of all your changes)

A stuff/loot/bloo.h # file is scheduled for addition

C stuff/loot/lump.c # file has textual conflicts from an update

D stuff/fish.c # file is scheduled for deletion

M bar.c # the content in bar.c has local modifications

$svn diff

(to show changes between current working directory and the same directory in the repository)

4.) Possibly undo some changes (Can also be done even with no network access to the subversion repository):

$svn revert

After running svn revert as a way to resolve local conflict with the repository copy, Run:

$svn resolve

To inform svn that the conflict has been resolved. You will now be able to successfully run svn update in case of previous conflicts.

5.) Resolve Conflicts (Merge Others’ Changes):

$svn update

$svn resolved

6.) Commit your changes:

$svn commit

$svn commit -m “Removed out of mem errors.”

$svn commit -F comment.txt

$svn commit –file comment.txt

6. Logs:

$svn log (use current working directory as the default target)

$svn log server_code

(current working directory/file is server_code)

$svn log -r 5:19

(shows logs 5 through 19 in chronological order of working directory)

$svn log -r 19:5

(shows logs 5 through 19 in reverse order of working directory)

$svn log -r 8

(shows log for revision 8 of working directory)

$svn log -r 8 -v

(shows verbose? log for revision 8 of working directory)

7. Diffs (Changes):

$svn diff

$svn diff -r 3 rules.txt

(or svn diff –revision 3 rules.txt)

$svn diff -r 2:3 rules.txt

(revisions 2 and 3 are directly compared)

$svn diff -c 3 rules.txt

(compare changes between current revision and revision 2)

8. Browse a file directly:

svn cat -r 2 rules.txt

svn cat -r 2 rules.txt > rules.txt.v2 (send cat output directly to a file)

9. Browse a folder directly:

svn list http://svn.collab.net/repos/svn

svn list -v http://svn.collab.net/repos/svn

10. Fetching older repository snapshots:

$svn checkout -r 1729

(Checks out a new working copy at r1729)

$svn update -r 1729

(Updates an existing working copy to r1729)

11. If you’re building a release and wish to bundle up your files from Subversion but don’t want those pesky .svn directories in the way, then you can use svn export to create a local copy of all or part of your repository sans .svn directories. As with svn update and svn checkout, you can also pass the – -revision switch to svn export:

$svn export http://svn.example.com/svn/repos1

(Exports latest revision)

$svn export http://svn.example.com/svn/repos1 -r 1729

(Exports revision r1729)

12. Cleanup if a Subversion operation is interrupted (if the process is killed, or if the machine crashes, for example), the log files remain on disk. By re-executing the log files, Subversion can complete the previously started operation, and your working copy can get itself back into a consistent state.

$svn cleanup

13. Revision specifiers:

HEAD: The latest (or “youngest”) revision in the repository.

BASE: The revision number of an item in a working copy. If the item has been locally modified, the “BASE version” refers to the way the item appears without those local modifications.

COMMITTED: The most recent revision prior to, or equal to, BASE, in which an item changed.

PREV: The revision immediately before the last revision in which an item changed. Technically, this boils down to COMMITTED-1.

$svn diff -r PREV:COMMITTED main.c

(shows the last change committed to main.c)

$svn log -r HEAD

(shows log message for the latest repository commit)

$svn diff -r HEAD

(compares your working copy with all of its local changes to the latest version of that tree in the repository)

svn diff -r BASE:HEAD main.c

(compares the unmodified version of foo.c with the latest version of foo.c in the repository)

$svn log -r BASE:HEAD

(shows all commit logs for the current versioned directory since you last updated

$svn update -r PREV main.c

(rewinds the last change on foo.c, decreasing foo.c’s working revision)

$svn diff -r BASE:14 main.c

(compares the unmodified version of foo.c with the way foo.c looked in revision 14)

14. Checkout based on revisions:

$svn checkout -r {2006-02-17}

$svn checkout -r {15:30}

$svn checkout -r {15:30:00.200000}

$svn checkout -r {“2006-02-17 15:30″}

$svn checkout -r {“2006-02-17 15:30 +0230″}

$svn checkout -r {2006-02-17T15:30}

$svn checkout -r {2006-02-17T15:30Z}

$svn checkout -r {2006-02-17T15:30-04:00}

$svn checkout -r {20060217T1530}

$svn checkout -r {20060217T1530Z}

$svn checkout -r {20060217T1530-0500}

15. Logs based on revisions:

$svn log -r {2006-11-28}

$svn log -r {2006-11-20}:{2006-11-29}

16. Properties of files:

property ‘copyright’ set on ‘calc/button.c’

$svn propset license -F /path/to/LICENSE calc/button.c

property ‘license’ set on ‘calc/button.c’

$svn propedit copyright calc/button.c

No changes to property ‘copyright’ on ‘calc/button.c’

property ‘copyright’ set on ‘calc/Makefile’

property ‘copyright’ set on ‘calc/button.c’

property ‘copyright’ set on ‘calc/integer.c’

$svn proplist calc/button.c

Properties on ‘calc/button.c':

license

$svn propget copyright calc/button.c

$svn proplist -v calc/button.c

$svn propset license ” calc/button.c

$svn propdel license calc/button.c

And specify the revision whose property you wish to modify

17. Locking files:

$svn lock banana.jpg -m “Editing file for tomorrow’s release.”

‘banana.jpg’ locked by user ‘harry’.

$svn status

K banana.jpg

$svn info banana.jpg

Path: banana.jpg

Name: banana.jpg

URL: http://svn.example.com/repos/project/banana.jpg

Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec

Revision: 2198

Node Kind: file

Schedule: normal

Last Changed Author: frank

Last Changed Rev: 1950

Last Changed Date: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)

Text Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)

Properties Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)

Checksum: 3b110d3b10638f5d1f4fe0f436a5a2a5

Lock Token: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e

Lock Owner: harry

Lock Created: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)

Lock Comment (1 line):

Editing file for tomorrow’s release.

$svnadmin lslocks /usr/local/svn/repos

$svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg

Force out someone else’s lock:

$svn unlock –force http://svn.example.com/repos/project/raisin.jpg

Force a lock over someone else’s

$ svn lock –force raisin.jpg

18. Creating branches:

$svn checkout http://svn.example.com/repos/calc bigwc

A bigwc/trunk/

A bigwc/trunk/Makefile

A bigwc/trunk/integer.c

A bigwc/trunk/button.c

A bigwc/branches/

Checked out revision 340.

Now create the branch;

$cd bigwc

$svn copy trunk branches/my-calc-branch

$svn status

A + branches/my-calc-branch

$svn commit -m “Creating a private branch of /calc/trunk.”

Adding branches/my-calc-branch

Committed revision 341.

You can do all the above in one step (Recommended way):

$svn copy http://svn.example.com/repos/calc/trunk \

http://svn.example.com/repos/calc/branches/my-calc-branch \

-m “Creating a private branch of /calc/trunk.”

Committed revision 341.

Merging branch to main trunk (Assuming you are in the working branch directory)

$svn merge -c 344 http://svn.example.com/repos/calc/trunk (merge change revision number 344 on your working directory branch)

U integer.c

$svn status

M integer.c

Merging while specifying the destination and target:

$svn merge -c 344 http://svn.example.com/repos/calc/trunk my-calc-branch

U my-calc-branch/integer.c

$svn merge http://svn.example.com/repos/branch1@150 \

http://svn.example.com/repos/branch2@212 \

my-working-copy

$svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy

$svn merge -r 100:200 http://svn.example.com/repos/trunk

Previewing merges:

$svn merge – -dry-run -c 344http://svn.example.com/repos/calc/trunk

U integer.c

(- -dry-run is a double dash without spaces. Word press munges the double dash into one when put together.)

$svn status

(nothing printed, working copy is still unchanged)

Merging branch changes into trunk:

$cd calc/trunk

$svn update

At revision 405.

$svn merge -r 341:405http://svn.example.com/repos/calc/branches/my-calc-branch

U integer.c

U button.c

U Makefile

$svn status

M integer.c

M button.c

M Makefile

Examine the diffs, compile, test, etc…

$svn commit -m “Merged my-calc-branch changes r341:405 into the trunk.”

Sending integer.c

Sending button.c

Sending Makefile

Transmitting file data …

Committed revision 406

Undo a merge:

$svn merge -c -303 http://svn.example.com/repos/calc/trunk

$svn merge –revision 303:302http://svn.example.com/repos/calc/trunk

U integer.c

$svn status

M integer.c

$svn diff

(Verify that the change is removed)

$svn commit -m “Undoing change committed in r303.”

Sending integer.c

Transmitting file data .

Committed revision 350.

Merging from branch to trunk:

$cd trunk-working-copy

$svn update

At revision 1910.

$svn merge http://svn.example.com/repos/calc/trunk@1910 \

http://svn.example.com/repos/calc/branches/mybranch@1910

U real.c

U integer.c

A newdirectory

A newdirectory/newfile

Resurrecting deleted items:

$svn copy -r 807 \

http://svn.example.com/repos/calc/trunk/real.c ./real.c

$ svn status

A + real.c

$svn commit -m “Resurrected real.c from revision 807, /calc/trunk/real.c.”

Adding real.c

Transmitting file data .

Committed revision 1390.

Traversing branches:

$cd calc

$svn info | grep URL

URL: http://svn.example.com/repos/calc/trunk

$svn switch http://svn.example.com/repos/calc/branches/my-calc-branch

U integer.c

U button.c

U Makefile

Updated to revision 341.

$svn info | grep URL

URL: http://svn.example.com/repos/calc/branches/my-calc-branch

Making releases using tags (snapshot of a directory at a given instant in time)

$svn copy http://svn.example.com/repos/calc/trunk \

http://svn.example.com/repos/calc/tags/release-1.0 \

-m “Tagging the 1.0 release of the ‘calc’ project.”

Committed revision 351.

Remove your branch after merge:

$svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \

-m “Removing obsolete branch of calc project.”

Committed revision 375.

Commit a log message correction:

$echo “Here is the new, correct log message” > newlog.txt

$svnadmin setlog myrepos newlog.txt -r 388

Migrate repository:

Create the dump files first:

$svnadmin dump myrepos -r 23 > rev-23.dumpfile

$svnadmin dump myrepos -r 100:200 > revs-100-200.dumpfile

Load the dump files into the new repository:

$svnadmin dump myrepos -r 0:1000 > dumpfile1

$svnadmin dump myrepos -r 1001:2000 –incremental > dumpfile2

$svnadmin dump myrepos -r 2001:3000 –incremental > dumpfile3

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.

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:

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
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:

Window → Perspective → CVS Repository Reporting

Figure: Open CVS Perspective

Figure: CVS Repository Exploring Perspective

Connecting to a CVS Repository

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

Open the CVS perspective (see previous section).
Right mouse click in the CVS Repositories window.
1. From the right mouse click menu select New → Repository Location ...

Complete the Add CVS Repository dialog as follows:
- For Location Host, enter ase.csc.ncsu.edu
- For Location Repository path, enter the path of the cvs repository. You will be using the repository located in your account's cvsroot directory/folder (in our server as "/cvs/root").
- For Authentication User, put your server account user-id.
- For Authentication Password, put your server account password.
- For Connection Connection Type, select extssh from the drop-down list.
- Check Validate Connection on Finish if it is not already selected.
  - Click the Finish button.

After validation, CVS Repositories window in Eclipse will show the connected repository. Note that you can have multiple repositories.
1. 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

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:

Select these files, right click to get the context menu. From the menu, select Team->Add to cvsignore.
You'll see that these items not longer show cvs info next to them in the explorer.
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