Version Control

As I discussed Subversion a year ago, dated back to July, 2006, it’s of great functionalities compared with the old versioning system, CVS. Currently, finally I have a chance and time to try it out.

The learning curve of SVN is comparatively easy, perhaps it’s due to the similar structure and interface to CVS. I just used two days to catch it up and switching a project from CVS to SVN successfully.

The major idea of SVN is the fact that it controls versions for a bunch of files, instead of one version for one file. In real case, we developers add a feature to software by manipulating bunch of files. Using CVS, we need to set up clear policy on making commit logs in order to let other developers know what you did for that feature. In case someone doesn’t follow the policy, everything will be messed up. For SVN, you commit a few files by saying these changes are for the same feature. Then, other developers are clear that why did you modify those files.

Moreover, one thing that is good for SVN is the better API I think. I am not sure about the actual infrastructure, but the fact is that there are many web applications, particularly issue trackers, that can query the SVN repository to display many different kinds of reports. For instance, I used one open-source software namely “Trac” which helps me relates the issue tracking progress to the changes on SVN. Trac can also query the SVN repository for revision comparison.

I can see switching to SVN is a trend in version control system development. At least many open source project has already switched to the SVN repository. It is easy to install, easier to control, and most importantly it is similar to using CVS as a client.

Install Instructions of Subclipse (SVN support on Eclipse): http://subclipse.tigris.org/install.html

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

Trac Project: http://trac.edgewall.org/

After start using the branch, merge and tag technology provided by CVS, it comes up to me with some concerns - naming convention of those tags.

Since the name for these can be anything designed by the users of CVS, we should make some conventions, so that users can clearly understand the under meanings.

Something I want:

1. The names should clearly describe whether it is tag for version or branch.
2. The names should describe the version of the tag.
3. It should show me the projects it belongs to.
4. The tags should only be created by a project leader (it’s for better project management)

References:

A Project in Stanford - http://smb.slac.stanford.edu/research/developments/blu-ice/dcsAdmin/node7.html

An example - http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/doc/CONVENTIONS

Currently, there is a new Version Management technology that comes up with attention. It is named Subversion (SVN). It’s new to me and I just know people start using it because they doubt the function of CVS being commit the files one by one.

The following article talks about how to use SVN with Eclipse. Let’s start with it and look at the “power” of SVN.

Quoted from RootPrompt.org:

From the beginning, Eclipse included tight integration with the Concurrent Versions System (CVS) in order to provide access to change-management capabilities. Now, many projects — notably those run by the Apache Software Foundation — are using a different change-management system: Subversion. This article demonstrates how to add Subversion support to Eclipse and how to perform basic version-control activities from the IDE.

In these few weeks, I’m working on the conventions of coding stuff in my new company. One of the issues is CVS

CVS, a tool which helps to keep track on the versions of files, source codes, documents. A company must benefit from CVS a lot, if it really uses the functions efficiently. In fact, it seems not the case in my company.

The use of CVS in my company does not have a long history, many of my colleagues don’t even have the mindset on version control in one or two years before. After introducing CVS, they learnt to keep versions at least in each release. But, they just take CVS as a backup tool, and would commit the whole project, including dummy files, compiled files, and also unchanged files. This must not an efficient use of CVS. That’s also the reason why I would like to set up some conventions on using CVS. Here will collect some information from the web.

http://ximbiot.com/cvs/manual/

http://www.bairov.com/2005/09/28/cvs-naming-convention/

http://www.eclipse.org/articles/Article-CVS-branching/eclipse_branch.html