- Shopping Bag ( 0 items )
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?
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.
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 developerhas '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:
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:
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:
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...