Home arrow BrainDump arrow Page 2 - Lessons Learned Managing Software Development in Startups

Source Code Management - BrainDump

This article outlines the process of setting up a source code management system, evaluating the pros and cons of Razor and CVS, and compares BugTracker and GNATS.

  1. Lessons Learned Managing Software Development in Startups
  2. Source Code Management
  3. Tracking Bugs
  4. Release Management and Lessons Learned
By: Rangachari Anand
Rating: starstarstarstarstar / 35
August 10, 2004

print this article



In the first few weeks of my company's existence, I was given the task of setting up a source code management system. After evaluating several alternatives, I decided to go with Razor from Visible systems. The main reasons were the modest cost per seat and the relatively good integration of bug tracking with code management. A trial version was available and we tried it out for a few weeks. The results of the trial were encouraging but ultimately Razor did not go over well with our developers when put into production. The main problems at that time (mid 2000) were:

  • The CLI client tool was hard to use (compared to CVS). Since a number of our users had worked with CVS, this was an important objection.

  • The Linux GUI client was a little clunky to use.

  • It turned out that the client and server had to be mutually reachable over the network. From what I could make out, this was necessary to allow the GUI to change file status in real time. Since our developers sometimes needed to access the server through a NAT (Network Address Translation) gateway, this turned out to be a big problem.

  • One more administration annoyance was that the Razor server was locked to a particular machine. Since our IT infrastructure was far from stable, this caused a lot of problems since each transfer of the license had to be approved by Visible.

Due to these problems, and also general resistance from the developers, we switched to using CVS for source code management. Since we were still in the experimental phase, there was no urgency in setting up a bug tracking system (which we lost by abandoning Razor).

Our CVS server is configured so that every CVS commit resulted in an email containing details of the commit being sent to all developers. Developers generally save commit emails in a folder in their mail reader and use the built-in search facility as a sort of a database to search for commit data.

In addition to each developer's private store of commit messages, we also use a tool called Bonsai that saves CVS commit messages in a relational database. A convenient web UI is available that allows one to perform complex queries against this database. Bonsai is invaluable at release time and when trying to determine whether a bug has actually been fixed.

There are many problems with CVS and these have been adequately described elsewhere, but the main issue that one needs to be aware of is a cultural one. CVS is great as long as its used in the way that its supposed to be used. In general CVS works best where the philosophy of development is along the lines of "it's better to ask for permission than to get permission". CVS is not a tool that works well with a "command and control" approach to managing development.  Despite this caveat, there will be times when it is necessary to lock a branch --  for example, when finalizing a release. This kind of locking can be added by using server side wrapper scripts although we have not done this so far.

The other big problem with CVS in the context of commercial development is the lack of any means to group commits together (i.e. changesets). When finalizing a release, for example, it's important for the release manager to know exactly which bugs have been fixed and which new features have added. This problem can be overcome by having developers include a reference to a bug or feature in the commit comments. If this convention is followed diligently, it is possible to track down all commits for a particular bug or feature with the help of Bonsai. However, mistakes often happen -- usually at the worst possible time. Developers may neglect to include a bug reference or may reference the wrong ones.

If we were starting today, and decided to use open source tools,  we would definitely use a better tool such as subversion. We have considered switching to subversion right away but have delayed a decision since the advantages do not appear to be compelling for now.

>>> More BrainDump Articles          >>> More By Rangachari Anand

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Apple Founder Steve Jobs Dies
- Steve Jobs` Era at Apple Ends
- Google's Chrome Developer Tool Updated
- Google's Chrome 6 Browser Brings Speed to th...
- New Open Source Update Fedora 13 is Released...
- Install Linux with Knoppix
- iPad Developers Flock To SDK 3.2
- Managing a Linux Wireless Access Point
- Maintaining a Linux Wireless Access Point
- Securing a Linux Wireless Access Point
- Configuring a Linux Wireless Access Point
- Building a Linux Wireless Access Point
- Migrating Oracle to PostgreSQL with Enterpri...
- Demystifying SELinux on Kernel 2.6
- Yahoo and Microsoft Create Ad Partnership

Developer Shed Affiliates


Dev Shed Tutorial Topics: