************************************* * * * DB/C Newsletter * * November 2003 * * * ************************************* News and Comments As promised in the January 2003 DB/C Newsletter, this month's article is about how source code control is used in the DB/C DX developer community. To write this article I talked with about 25 DB/C DX developers. This non- scientific sample covers a good variety of DB/C DX developers - application software vendors, end user organizations, lone programmers, small groups of programmers, and a few larger (20 or more) programmer shops. One of the reasons that I chose to write this article is to get more people to use Eclipse/DDT. The number of DB/C DX programmers who have adopted Eclipse/DDT as their development environment is relatively small. This is understandable as Eclipse/DDT was released just three months ago. However, I've recognized that there are two large obstacles to adoption of Eclipse/DDT. The first obstacle is the text editor. Text editors are like religions - everybody has their own flavor that they think is best and aren't willing to easily part with. The DB/C source file editor in DDT is a good editor, but it's not vi, emacs, ultraedit, edit, etc. To embrace Eclipse/DDT, you need to go with the flow and use its source file editor. The second biggest obstacle is source code control. Although plugins are available for other source code control systems, CVS is so tightly and well integrated into Eclipse that it almost disappears. Unfortunately, few DB/C DX development shops are using CVS. This month's article provides details about what is actually being used today by DB/C DX developers. The tight integration of Eclipse and CVS doesn't necessarily mean that you need to use CVS for source code control, but many of the benefits will be missed if you don't. The bottom line is if you do your DB/C DX development on a Windows NT or later machine (even if UNIX is the deployment target), you really should look at Eclipse/DDT as your primary development tool - it is a great way to develop and maintain programs written in the DB/C programming language. don.wills@dbcsoftware.com ****************************************************************************** Source Code Control in the DB/C DX Developer Community Programmers who write programs in DB/C are no different than those who write programs in other programming languages. Their first and foremost objective is to write programs quickly that meet the needs of the user. Anything that gets in the way of fulfilling that objective is generally avoided unless the cost of avoidance is too great. Source file backup is the only impediment that the DB/C DX developer community is universally willing to endure, because the potential cost of lost source is large. Most programmers try to avoid all other impediments to reaching their objective - impediments like documentation, regression testing or source code control - unless they really can't avoid it. A source code control strategy is imperative for groups of programmers who are sharing duties of writing and maintaining common source code. Thus it was not surprising to find out that almost all lone programmers do not use any source code control strategy other than file backup. As the number of programmers in the group increases, the chance of using some sort of source code control increases. All large groups of DB/C DX developers are using some sort of source code control. Slightly more than half of the DB/C DX developers surveyed do not use any source code control strategy other than file backup. Slightly less than half do use some sort of source code control strategy. The percentage of developers actually doing source code control is probably less than that because people were somewhat embarrassed to voluntarily report that they didn't use any source code control system. DB/C DX source code control strategies fall into two groups - those using home-grown methods and those using free or commercial source code control software. About one third of those with a source code control strategy were using home-grown methods. Interestingly, the home-grown source code control strategies are similar to each other. Generally, a central library of source files is kept. When someone needs to change a file, a copy of the source file is made. Some indication is made that the source file is checked out. This is generally something like a special extension being added to the file, or in one case a physical card is updated to reflect the check out status. About half of those using formal source code control software are using CVS (or a derivative), and the other half are using Microsoft Visual SourceSafe. Two of the users of Visual SourceSafe described data integrity problems (lost source updates!). Even taking into consideration Microsoft's poor track record with regard to buggy software, these reports are surprising because source code control is the one place where data integrity is paramount. Several developers mentioned that they would be moving toward CVS. No one mentioned that they would be moving toward Visual SourceSafe. In summary, a majority of DB/C DX developers do not use source code control. Many recognize the importance of using formal source code control software, but feel that the cost is too high or that they don't have time to implement it in the short term. The beauty of Eclipse/DDT with CVS is that after getting over the big hump of moving from the current edit/compile/ test cycle to Eclipse, CVS comes with little added cost. The next time you are between projects, you should consider giving Eclipse/DDT/CVS a try. You won't regret it! ****************************************************************************** DB/C DX Class Schedule Class: DB/C DX Fundamentals Date: February, 2004 Location: Oak Brook, Illinois For information, send email to admin@dbcsoftware.com. ****************************************************************************** Subscribing to the DB/C Newsletter If you don't already have the DB/C Newsletter delivered to your email address and would like to have it emailed to you monthly, just send an email message to 'dbcnews-subscribe@dbcsoftware.com'. The newsletter will be delivered to the email address from which the message was sent.