Professional Linux Programming - Softcover

Neil Matthew And Richard Stones; Brad Clements; Andrew Froggatt; David J. Goodger; Ivan Griffin; Jeff Licquia; Ronald Van Loon; Harish Rawat; Udaya Ranawake; Marius Sundbakken; Deepak Thomas; Stephen J. Turnbull; David Woodhouse; Richard Stones; Christopher Browne

Softcover

ISBN 10: 1861003013 ISBN 13: 9781861003010

Publisher: Apress, 2000

Synopsis

As Linux increases its presence throughout the world as a target platform for professional application development, its growth as a powerful, flexible system offering many free development tools assures its place in the future. By giving you easy access to this comprehensive range of tools, supporting new and nascent technologies, at little or no cost, developing with Linux allows you to apply the solution that's right for you.

In this follow-up to the best-selling Beginning Linux Programming, you will learn from the authors' real-world knowledge and experience of developing software for Linux; you'll be taken through the development of a sample 'DVD Store' application, with 'theme' chapters addressing different aspects of its implementation. Meanwhile, individual 'take-a-break' chapters cover important topics that go beyond the bounds of the central theme. All focus on the practical aspects of programming, showing how crucial it is to choose the right tools for the job, use them as they should be used, and get things right first time.

Who is this book for?

Experienced Linux programmers and aspiring developers alike will find a great deal of practical information in this book on libraries, techniques, tools and applications. You should be familiar with a simple Linux system, have a good working knowledge of programming in C, and a basic understanding of object-oriented programming with C++ for the Qt/KDE chapters.

What does this book cover?

Data storage in Linux - including coverage of PostgreSQL, MySQL and XML

Implementation of Linux GUIs - covering both KDE and GNOME

Web-based interfaces - using the PHP module for Apache

Python - including extending and embedding the language

Using RPC and CORBA to construct distributed object-based applications

Versioning (with CVS), documentation, internationalization and project distribution

Distributed hardware solutions such as diskless Linux and Beowulf clustering

About this title

About the Author

Richard Stones and Neil Matthew are the authors of the first edition of Beginning Linux Programming. They are both experienced software professionals with many years' experience using and programming UNIX and Linux. They are also co-authors of the Wrox Press title, Instant UNIX.

The other contributors are a multi-author Wrox writing team of professional developers.

Excerpt. © Reprinted by permission. All rights reserved.

CVS

One of the things you should do at an early phase in your project is to set up a way of tracking changes to your project. This might just be the source code, or you might have some documents you wish to track as well. You should be tracking these items for two reasons: firstly so that you can discover what a build or document looked liked at some point in time, and secondly so that you can identify changes over time.

Of course you could just copy items to duplicated directories, with names corresponding to the date, but such a simple solution quickly becomes unmanageable where multiple developers are involved, and the timescale is longer than a few weeks.

If you are a developer working on your own, you may be tempted to think that source code control doesn't offer you much; after all, no one else is going to change the code, so you have full control. However, even the best developers make mistakes occasionally and need to go back to previous versions. Users may report a bug introduced in a minor revision, and rather than just track it down in the traditional way, it might be much more productive to have a look at how the code has changed in the affected area since the last release before the bug appeared. A source code control system can be an invaluable aid in these circumstances, allowing the tracking of exactly when, and how, code was changed.

Where there are multiple developers, the case is even stronger. Not only are there all the reasons that exist for single developers, but new and important reasons relating to peoples' ability to see who has changed what and when - it's then much easier to wind back changes in the event that another developer has 'got it wrong'. Providing people properly comment their changes, it's also possible to discover why they changed things, which can sometimes be very enlightening.

In short, there are many very good reasons to use a source code control system, and very few excuses for not doing so, given the choice of quality free tools available on Linux.In this chapter we will:

set up CVS explore using CVS to manage a project network CVS to enable true collaborative projects

Tools for Linux

Initially there was only one mainstream choice for source code control on Linux, which was RCS (the Revision Control System) from the GNU software tool set. Whilst RCS was, and still is, a very good and reliable revision control system, a lot of people (particularly on projects with several developers or with distributed development environments) have moved to use a newer tool - CVS, the Concurrent Versions System.

CVS originated as a number of shell scripts in 1986. Today's CVS code is mostly based on the work of Brian Berliner since 1989. There are three principal features that have allowed CVS to displace RCS as the tool of choice for managing changes to source code:

Its ability to be configured easily to operate across networks, including the internet. Its ability to allow multiple developers to work on the same source file simultaneously, in many cases being able to merge changes made to a project by many different developers automatically. Its significant improvements, over RCS, in handling of collections of files.

Add to this the fact that CVS is completely free, and you have a winning tool that you should probably consider learning how to use. In the course of this chapter, we're going to have a look at:

setting up and using CVS for a single user on a local machine setting up and using CVS for multiple-users across a network useful features and extensions to CVS, including network configuration and graphical clients

CVS is a rather complex system, and we will not have the space in a single chapter to cover every last detail of its use. However, we hope to show sufficient details that 95% of your needs will be met. You should then be well placed to investigate some of the more obscure features of CVS, should your needs be more exacting than those we've had space to cover.

In this chapter we will be concentrating on using CVS to manage source code. However you should remember that it's just as effective at managing changes to test data, configuration files or the utility scripts that your project is using. Indeed all aspects of your project can be stored in CVS.

CVS can also store your specifications, which are often even more valuable than the source code. However, if any of these are written in binary format, then you must tell CVS that the file is binary, and CVS will not be able to automatically report differences between versions. We will talk more about managing binary files later in the chapter.

Edition details

• Publisher: Apress
• Publication date: 2000
• ISBN 10: 1861003013
• ISBN 13: 9781861003010
• Binding: Paperback
• Language: English
• Number of pages: 1200