Socialpoints

As promised here is a follow-up to my initial post on getting started with CVS as your source control solution.

This post shows how to setup a CVS repository on a linux server.

Why Linux? A few reasons. Once you start to use source control, it rapidly becomes a central part of your development setup. The source code repository becomes a valuable asset. A valuable asset that you want to protect and ring-fence. For this reason a dedicated server is preferable to a shared solution (although this is also possible). At first you may think this is overkill, but as the repository grows larger, your development team grows, maybe you off-shore some development work.... it will start to look like a smart move. So getting back to why Linux, well assuming you're on a budget (who isn't!) you can take that old PIII machine that nobody wants any more, upgrade the disk drive, load a free download of your favourite Linux distribution (mine is RedHat) and you have a virtually free dedicated CVS server ready to go.

Make it secure.
Its beyond the scope of this article to go into details of securing your linux server, but since this server only has one job to do you can turn off every other protocol/service/port that is not required. Even if this server is not public now, it may be in the future. Worth considering.

Repository Setup
CVS comes as standard with many Linux distributions. Check if it is installed using rpm -q cvs
This should display the release of cvs loaded.
1. Set-up a cvs user on linux with a default group of cvs. All operations on the CVS repository will be under the authority of this user.
2. Login as cvs. Create a directory under the home cvs directory called repository. This will become the CVSROOT and the home of the repository files. Set the permissions on this directory by running chmod 770 /home/cvs/repository
3. Create the repository by running cvs -d /home/cvs/repository init
Thats it! You have a repository!

Separate Users
It is of great benefit to now set-up a linux user for each developer, because then each developer is automatically associated with each change they make to source code as they commit these changes, and a useful history builds up.

If you are using the eclipse IDE you can start to use this immediately with a secure connection through SSH.

Many other CVS client tools exist. In my next post I will discuss the various merits of some of these tools.

The topic of source control crops up fairly regularly on the coldfusion mailing list CF-Talk and rightly so for it is a critical part of good development practise.

We debated the need for source control at some length and over several months, finally settling on CVS.

With hind-sight we should have jumped in sooner since it is only by using a product that you really start to understand the issues involved.

So here over the next few days (or maybe weeks) I will post some of the experience we have gained with CVS including some practical tips on repository setup and practices that have worked well for us.

First of all I should explain that we chose CVS over SVN since at the time SVN was a less mature product than it is today, with less tools available. Today I might choose SVN in preference to CVS because SVN has fixed some of the minor niggles with CVS. Broadly speaking however, they work on the same principles and share the same commands and terminology.

How does CVS work?

Read more...

Its worth remembering that CVS on Linux is case sensitive to file and folder names and adopt a naming standard for projects, else it is possible for odd things to crop up...
Our CVS repository resides on a Red Hat Linux box. (CVS is supplied as part of the standard RH Linux package). Our development takes place in Windows XP Pro PC's using CFEclipse. While windows takes a relaxed view about the case of folders and files, linux does not! This does not often cause an issue because normally only one developer will create a file or folder and will therefore set the case of that file, however in a recent example two developers created a folder. Developer 1 created 'Selections' while developer 2 created 'selections'. Both created different files within this folder and both committed their changes to the CVS repository. The developers intended this to be one folder, but CVS on linux created two distinct folders. When either developer tried to either 'update' or 'checkout' this project to a windows environment an error is generated because it tries to create the 'selections' folder twice and cannot!
It is good really that the mistake gets highlighted in this way. The files from one folder need to be transferred to the other and then one of the folders deleted in the repository to sort things out.

Well everyone else seems to have a blog and so I decided to set one up for myself, partly so I know how its done and partly to share some technical stuff with a wider audience. I am using Raymond Camden's blogCFC and very nice it is too! Thanks Raymond! It only took about 45 minutes to set up the vanilla addition. Since then I have tinkered with some content and style. I did discover that CVS via eclipse ignores the folder called tags by default. The first time I thought it was just my mistake, the second time I thought I had better investigate. Sure enough 'tags' and 'TAGS' is part of the default ignore list because of course tags have their own meaning within CVS. To get around this you can right click on the tags folder and use >team>add to version control options.