************************************* * * * DB/C Newsletter * * January 2003 * * * ************************************* News and Comments Joe Remes has joined DB/C Software Company as a full-time employee replacing Jamie Findlay. We wish Jamie well in his future endeavors. Joe has been writing DATABUS programs for many years. His first DATABUS experience was on a Datapoint 5500 in 1978. Joe joined Subject, Wills & Company in 1987. At SWC, Joe has worked with many customers as an application programmer and consultant. Most of the applications he worked on were written in DB/C. In the last few years Joe has taught the three day DB/C Language Fundamentals class and has worked on several projects related to the internals of DB/C DX. We're happy to have Joe working with us. The start of beta testing and the final release of DB/C DX 13 have been delayed again. Software companies have moved away from using the term 'beta test' to describe prerelease software. I suspect that one of the reasons for not using the 'beta test' name is that the software being distributed for testing is not feature-complete. We have generally tried to adhere to the traditional definition of beta testing - that is, software that is feature-complete with documentation. Unfortunately, we're still a few months away from that situation with DB/C DX 13. However, we are now making available the major new feature of DB/C DX 13 in a form we are calling 'very early access'. That is, the software does not have all of its planned features and there is minimal documentation. This major new feature of DB/C DX 13 is the DB/C Development Toolkit (DDT) for Eclipse. Eclipse with DDT is a complete replacement for FDE that was included with the Windows versions of DB/C 9 and DB/C DX. FDE had limited capabilities. Customers who used FDE generally did so only for designing GUI resources - they did not use FDE for any other aspects of program development. In comparison, Eclipse with DDT provides a seamless editing, compiling and testing environment that is a joy to work with. Eclipse/DDT is useful for development and testing of both character mode and GUI mode DB/C DX programs. One important aspect is that Eclipse/DDT will be available for both UNIX and Windows. So if you are interested in giving it a try, contact me via email. One of the most attractive features of Eclipse is its integration with source code control systems, and specifically with CVS which is probably the most widely used source code control system. This month's article is about why source code control is important. The article is a reproduction of a white paper written by David Thornley. You can find out more about David and source code control at http://www.thornleyware.com. If you are interested in finding out more about CVS, I suggest you read a second article by David titled 'CVS White Paper'. This article is available at http://www.thornleyware.com/whitepapers/cvs.html. There are two primary resources for CVS. The main web site for CVS is http://www.cvshome.org. The book titled 'Open Source Development with CVS' by Karl Fogel is the authoritative reference for CVS. I plan to write a follow-up article later this year about real-world usage of source code control and DB/C DX. So regardless of how primitive or sophisticated your source code control system is, if you are willing to share your experiences, I would like to talk with you via phone or email. don.wills@dbcsoftware.com ****************************************************************************** Source Code Control White Paper by David Thornley Your shop undoubtedly has a large amount of source code, built up over the years in a more or less organized fashion. This may be for sale, or (more likely) for internal use. It represents a lot of work, and hence a lot of expense. It serves many needs, and is the result of a great deal of analysis and design. You have responded to the needs of your customers, whether these customers are internal or external, and many of their complaints have been fixed. Your code base is valuable, since it represents so much work and is useful for the customers. The most primitive way [to do source code control] is to back up the system regularly, which means you can at least retrieve the latest version. This leaves a lot of potential questions and difficulties. . You change something, decide to change it back, and can't find the original. . There's strange-looking code in a program. Why is it there? . You get a report that something stopped working last Wednesday. What changed then? . Joe fixed a problem last week. What changes did he make? . Sarah and Bill change the same program at the same time. . Anne fixed a bug last week, and now her changes are gone. . You need to make large changes in part of your code, and still fix bugs in the meantime. . You have code from somewhere else, and need to maintain local changes through several releases. . You have a large, slowly changing code base, and the size of keeping multiple backups is getting out of control. . You solved the above problem with incremental backups, and now can't easily find what the version was on a certain date. A good SCM system will address all of these, and more. There have been a great many systems designed for this purpose, that serve with various degrees of success. Any one of them will help by keeping track of your code, allowing you to reproduce previous versions, and logging any changes made. When selecting a source code control system, you need to consider several things. You want it to be seen as a tool by your developers, not as a hindrance or a source of annoyance. You want it to fit in to your preferred development process and not interfere with it. You want it to be inexpensive to install and use, counting all costs. You want it to be reliable, and not lose information. Most of all, you want it to do the things you need it to do. For these criteria, CVS is an excellent choice for many development shops. There are other things to consider. What sort of network performance do you need? If you want to have developers working at home, or at multiple sites, you want to allow them access, without jeopardizing security. If developers may not be always connected, you want them to be productive anyway. What sorts of platforms do you have? You may have a mixture, perhaps some Microsoft Windows and a few different versions of Unix, or even some Macintoshes. Whatever you choose needs to run on all the platforms your people will work on. Do you need to support multiple releases, or one at a time, or do you just deploy immediately onto production systems? In the latter case, you don't need any sort of release handling. How many people and how much code do you have? The solution you choose has to work on the scale you need. Do you have software from elsewhere, and need to maintain local changes through version changes and upgrades? *** This article is Copyright 2002 by David H. Thornley. *** Permission granted for verbatim copying and use within an organization. ****************************************************************************** DB/C DX Class Schedule Class: DB/C DX Fundamentals Date: To be determined 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.