Socialpoints

We are in the process of switching from CVS to SVN as our source control system. It is nearly four years ago that we first started using CVS and it has served us well. The main two reasons for changing are

• that SVN is an active project that continues to improve and be developed
• that using svn with apache allows much better/granular/easy to administer access control than CVS


There does appear to be a downside and that is simply that the Eclipse plugins are just not quite as sweet as the integrated CVS interface that comes bundled with Eclipse. As I get to grips with it more I will post the main issues here and to the appropriate mailing lists. At least these are active projects which can only improve.

One of our main reasons for switching to eclipse (and its CF plugin CFECLIPSE) was the excellent CVS (concurrent versioning system) integration.

It smooths out the kinks in CVS to make it an intuative tool to use.

For example if you move a file from one folder to another CVS wants you to delete and add very specifically, but eclipse just handles this for you in the background making it seem like a single commit operation.

All this power is available from the Navigation view (shows your projects and the files in them, in a tree structure) on the right click 'Team' menu. From here you can commit or update as appropriate.

One of the other Team options is the 'Synchronize' view

I tended to avoid this at first preferring to update and commit myself, however I'm now using this as my default view of the project from a CVS point of view. It gathers up incoming and outgoing changes that are pending and also highlights any conflicts (where you have edited a file and meanwhile another developer has commited a later version) and allows you to resolve those conflicts by displaying a diff of the two versions.

You can right click and update, commit, and resolve conflicts directly from this menu on individual files or on groups of files selected.

If you use CVS and CFECLIPSE give it a try.

A powerful feature of CVS (and other related source control systems) is the ability to create a branch in your source code repository. (The repository is just the name for where CVS stores the source code for your projects)

Conceptually the branch is a completely separate set of source code, a copy of all the code that makes up your project, as at the point when you create the branch.

After branching you are able to make changes either to the main set of source code, or to source code on the branch and these changes are kept separate for you.

So the question is why would you want to do this?

There are many different scenarios that may arise in a project that will lead to the need for a branch.

I will mention at least one in a moment, but first I will try and present the more generic reasons to use branches.

A branch should be used when a significant piece of development work needs to take place in parallel with other development work on the same project, and to carry out these two sets of work on the same code, would cause conflicts of some kind.

So here is one example.

My order processing system went live last week, but a few teething troubles are still coming to light and as they crop up the support team are doing fixes and getting these to testing and then production as rapidly as possible. Meanwhile the development team are now working on the phase 2 enhancements to this system. Some of these phase 2 enhancements require some major changes to existing code. Since there is a team working on this phase 2 work they want to commit code and share their progress.

If this was all done on a single code base you can see how we would have a problem keeping the phase 2 changes from getting mixed up with the fixes to the released code.

One or other of these lines of code need to be on a branch. Either the branch could be created to represent the released version of code or the phase 2 development can be on a branch.

Different projects and teams and patterns of work will lead to different ways to use branches but they are certainly an invaluable tool.

The Eclipse IDE makes creating and managing branches easy with all the commands on the team menu.

Of course at some point you will no longer want separate versions of code; in my example we would want to release phase 2, or you we may want to incorporate the bug fixes into the phase 2 work as we go. Either way we would need to merge the two sets of source code.

Sounds scary right? Well again Eclipse will make it fairly painless providing lots of great tools to handle code conflicts, although ultimately its down to you the developer to retest the merged code!

In the normal course of development a team can work on the main trunk of the code. As they commit changes these are added to an automatic 'tag' within CVS called 'HEAD'.

The HEAD revision always represents the latest committed version of every source file in the repository.

When you first start using CVS the HEAD revision is good enough but as things develop and you work with larger projects you may wish to have finer control. That's where 'tags' come in.

Lets assume you are the project leader and are coordinating the development work. Once functions A, B and C are completed you would like to deploy the project to the staging server to show the client and get some feedback. Having talked to the developers involved and found that the last change has been committed you checkout the HEAD revision to your local machine and test it yourself. If all is well this would be a great time to create your own tag.

You can call this what you like it would be good to invent a convention maybe a version like v0_1_0

There are a few peculiarities about CVS tag names - they have to start with a letter and cannot include these characters $,.:;@|

Now development can continue with other changes committed to the HEAD revision, but you can always checkout and deploy to a development or test or staging or live or production server the v0_1_0 version for the entire project.

Note a tag is entirely separate from the revision numbers that CVS gives each source file. These are incremented automatically as you commit a change, so one file may be 1.1 but another may be 1.9. They can both be tagged v0_1_0 since together they form a coherent snap shot of the project that you want to capture and be able to recreate.

My next post will cover branching and merging. Under the bonnet (thas 'hood' for you Americans :-) CVS treats tags and branches in a very similar way but branches give you a whole lot more control of complex projects.

Once you have finally decided that your team really needs Source Control (even if your team is just you for now!), and you have set up a repository (see part1 and part2 posts), you will need some client side tools to get your source code in and out.

Lots of the online documentation on CVS is a bit old (except mine of course :-) and it assumes that you are developing in C on a unix box. Nothing wrong with that, but it may not be the most common or relevant stuff for us CF'ers! You are more likely to have a windows based PC (appologies to MAC users, just don't have the experience there) as your development platform. The great news is that you will be spoilt for choice of CVS client tools on the windows platform! Here are a handful that I originally evaluated.

Read more...