RimuHosting: Mighty Linux Servers.  Support Worth Raving About
Plans & Pricing
Server Recommendation Tool
Server Types
  VPS
  Semi-dedicated Server
  Dedicated Server
Server Locations
  Dallas
  London
  Australia
VPS Technology
Hardware
Data Centers
Linux Distributions
Applications
Maintenance Notices
Support Ticket
Control Panel
HOWTO Articles
Forums
VPS control panel
Billing details
Receipts
Contact details
DNS
Reverse DNS
Console-over-SSH
FTP backup space
Backup mail server
About
Staff
News
Customer Testimonials
Sales Inquiry
Link To Us
Terms and Conditions
Site Map

Order VPS Hosting
Order a VPS, Semi- dedicated or Dedicated server in Dallas, London or Australia.

Get Assistance
Ask our support team about your hosting requirements.


Host where the staff takes pride in making customers happy

[The Xen VPS performance is] pretty impressive. It rebuilds my whole NanoBlogger static site in 7.62 seconds. My previous _dedicated_ server with a physical AMD Sempron @ 1.67GHz and 256MB of RAM took 11.89 seconds to do the same

- Guillem (about his RimuHosting VPS being 36% faster than his previous host's dedicated server) (#150/269)
Home > Support > HOWTO List > Applications > CVS

Application-related howtos

Setting Up A CVS Project

You've created your code.  It works great.  Now you want to make some changes.  But in case it all goes wrong, you want to be able to back out the changes.

You need CVS (or some random backup system, but CVS will do a better job).

Setting up a CVS Server

If you do not already have a CVS server, you can set one up on your RimuHosting server.  Just log in and run:


# you need the CVS applications
apt-get -y install cvs
# this tells cvs init where to create the CVSROOT directory
export CVSROOT=/usr/local/cvsroot
# create the CVSROOT directory with all the config files cvs needs
cvs init

# create a group for 'cvs' users.  This group may already exist, so ignore any error
groupadd cvs
# give that group ownership of the cvs repository
chown -R root:cvs /usr/local/cvsroot
# set the sticky bit so that files created by a group member stay owned by the group
chmod -R g+srw /usr/local/cvsroot/

Then for each Unix user that needs access to the repository, run: usermod -G cvs somecvsusername.

If you get an error like:


cvs import: cannot make path to /usr/local/cvsroot/someproj: Permission denied
cvs import: Importing /usr/local/cvsroot/someproj/someproj
cvs import: ERROR: cannot mkdir /usr/local/cvsroot/someproj/someproj -- not added: No such file or directory

Then check that the user is in the cvs user's group, and that the sticky bit was set for the cvs group on the /usr/local/cvsroot directory.

The /usr/local/cvsroot/CVSROOT directory created by cvs init includes the cvswrappers file.  You should probabably add a list of your binary file types there (see below).

Creating a CVS Project

Go to the directory where you have your files.  Say /usr/randomproject.

Create a .cvsignore file (note the dot prefix).  On each line, enter the files you don't want to import.  Enter a directory name if you don'twant to import that.   Use wildcards if you want.

e.g. contents could be:

*.jpg
confdir

Create a cvs_setup.sh file.  e.g.:


export CVS_RSH=ssh
export CVSROOT=:ext:yourloginname@yourcvsserver.com:/usr/local/cvsroot

CVS consists of a client program.  And a server.  The CVS_RSH setting tells CVS to use SSH when connecting to the server.  It means you don't have to run anything else on your CVS server other than the SSH daemon (i.e. no pserver, no rsh).   Using SSH also means that all your network traffic will be kept nice and secure.

Run the setup command: . cvs_setup.sh (i.e. dot space cvs_setup.sh)

Now, from inside your project directory, import your files (actually you may just want to check your server's cvswrappers file first, see below): cvs import -m "your import messsage" the_project_name_or_directory_name_i_want_to_use vendor initialtag.  e.g.


cvs import -m "initial import" projectalpha joecoder projectalpha_v_1_0

You should get a message saying something like: No conflicts created by this import.

Doing the import doesn't place the imported files (on your hard disk) under cvs 'control'.  So what you'll often do is move the original files away, and then do a cvs checkout to work with the files you've checked out:

cvs checkout the_project_name

e.g. cvs co uml

If you want the directory you create from the checkout to differ from the project name, try:

cvs co -d yournewdirname uml

Further reading:

https://www.cvshome.org/docs/manual/cvs-1.12.8/cvs_3.html#SEC38

http://www.loria.fr/~molli/fom-serve/cache/159.html

Dealing with Binary Files: cvswrappers

Before importing, make sure that your CVS repository has a decent cvswrappers file (usually on your CVS server at /usr/local/cvsroot/CVSROOT/cvswrappers). This file tells CVS which files are mergeable (when two developers both change the same file) and which files are binary (for CR/LF translation to different platforms).  Without the correct contents in this file, CVS will do things like alter (ruin) the content of gif and jpeg files (first hand experience on that one).


##
# Non-mergeable files
##
*.a -k 'b' -m 'COPY'
*.ai -k 'b' -m 'COPY'
*.bin -k 'b' -m 'COPY'
*.bitmap -k 'b' -m 'COPY'
*.bmp -k 'b' -m 'COPY'
*.BMP -k 'b' -m 'COPY'
*.BPT -k 'b' -m 'COPY'
*.BRO -k 'b' -m 'COPY'
*.class -k 'b' -m 'COPY'
*.dll -k 'b' -m 'COPY'
*.DLL -k 'b' -m 'COPY'
*.doc -k 'b' -m 'COPY'
*.DOC -k 'b' -m 'COPY'
*.dvi -k 'b' -m 'COPY'
*.eps -k 'b' -m 'COPY'
*.EPS -k 'b' -m 'COPY'
*.exe -k 'b' -m 'COPY'
*.EXE -k 'b' -m 'COPY'
*.fm -k 'b' -m 'COPY'
*.gif -k 'b' -m 'COPY'
*.png -k 'b' -m 'COPY'
*.GIF -k 'b' -m 'COPY'
*.gmo -k 'b' -m 'COPY'
*.gz -k 'b' -m 'COPY'
*.hqx -k 'b' -m 'COPY'
*.icns -k 'b' -m 'COPY'
*.ico -k 'b' -m 'COPY'
*.ICO -k 'b' -m 'COPY'
*.image -k 'b' -m 'COPY'
*.ins -k 'b' -m 'COPY'
*.jar -k 'b' -m 'COPY'
*.jpg -k 'b' -m 'COPY'
*.jpeg -k 'b' -m 'COPY'
*.lib -k 'b' -m 'COPY'
*.MAK -k 'b' -m 'COPY'
*.mcp -k 'b' -m 'COPY'
*.o -k 'b' -m 'COPY'
*.obj -k 'b' -m 'COPY'
*.OPN -k 'b' -m 'COPY'
*.pdf -k 'b' -m 'COPY'
*.pgp -k 'b' -m 'COPY'
*.ppt -k 'b' -m 'COPY'
*.prj -k 'b' -m 'COPY'
*.ps -k 'b' -m 'COPY'
*.PS -k 'b' -m 'COPY'
*.psd -k 'b' -m 'COPY'
*.res -k 'b' -m 'COPY'
*.snd -k 'b' -m 'COPY'
*.sit -k 'b' -m 'COPY'
*.tar -k 'b' -m 'COPY'
*.tgz -k 'b' -m 'COPY'
*.tif -k 'b' -m 'COPY'
*.TIF -k 'b' -m 'COPY'
*.tiff -k 'b' -m 'COPY'
*.TIFF -k 'b' -m 'COPY'
*.wordbreak -k 'b' -m 'COPY'
*.xbm -k 'b' -m 'COPY'
*.XBM -k 'b' -m 'COPY'
*.z -k 'b' -m 'COPY'
*.Z -k 'b' -m 'COPY'
*.zip -k 'b' -m 'COPY'
*.ZIP -k 'b' -m 'COPY'

Application Environment Setup Using /etc/profile.d/*

When a user logs in, environment variables are set from various places.  That includes /etc/profile (for all users).

Then all the files in the /etc/profile.d directory.

Then ~/.bash_profile, then ~/.bashrc.

/etc/profile.d/ is a good place to put your application specific setups.  For example, I always use SSH for CVS (cf. RSH).  So I use:

echo "export CVS_RSH=ssh" >> /etc/profile.d/cvs.sh
chmod +x /etc/profile.d/cvs.sh

See also: http://www.linux-migration.org/ch02s03.html