Development tools: Version control, build tools, and integrated development environments 1 HFOSS 2010 Faculy Workshop 18 May 2010 1 CC by-nc-sa 3.0 Development tools
Why do we need version control? With any degree of complexity in application, single file will undergo many changes. Need a way to checkpoint changes: To identify who made what changes; To back out of changes if necessary; To control overlapping changes made be different developers. Version control system provides method of keeping track of checkpoints and controlling conflicting changes. Development tools 1 / 12
Really old version control (RCS/CVS) RCS/CVS versioning: on a given file, checkpoints marked by version numbers. Version number consists of period-separated list of numbers (in CVS, always an even number of numbers). Each subsequent checkpoint increases one of the numbers. Each sequence of checkpoints belongs to a branch, identified as an odd number of numbers separated by periods; checkpoint number is appended as one more digit. E.g.: Version 1.3.2.7 is the 7-th checkpoint on branch 1.3.2. Branch with single digit is main trunk. Development tools 2 / 12
Set of all changes to a file represented by a forest 1.2.2.1 1.2.2.2 1.1 1.2 1.3 1.4 1.3.2.1 1.3.2.2 1.3.2.3 Of course, typically want to be able to merge branches back into main trunk. Development tools 3 / 12
The main complaint Most applications consist of multiple files, each changed (probably) independently of each other. How to synchronize version numbers of files with release numbers of product? CVS approach: file version numbers essentially CVS internal bookkeeping data. Use tags to identify the versions associated to a particular product release. Tag is a symbolic name associated to a group of files that can cut across version numbers. E.g., can have tag cool app 1-0-p1 associated to A.java 1.3, B.java 1.7, and C.java 1.4.2.1. Need naming convention for tags; CVS does not enforce one (this is one example: app maj-min-patch). Development tools 4 / 12
Old version control (Subversion) Every checkout and commit is of every file in the project. Each commit increments a global version counter. A branch is a complete (named) copy of the project. Branches do not get their own version numbers! Usual structure of a Subversion repository: trunk: the main line of development. branches: one subdirectory for each major task. Of course, must have a way to merge branches back into the trunk. How can this be done efficiently? The Subversion back-end is actually a database! Development tools 5 / 12
Multiple developers: restricted checkouts Only one developer allowed to modify a given source file at a time. When developer checks out source file, a lock is placed on it. Conflicting changes not possible. But often too restrictive; prevents changes to independent parts of source file by different developers, so slows development. Even worse: with Subversion, single developer has to check out entire project, preventing work any any part of the project. Multiple developers: unrestricted checkouts Multiple developers allowed to modify a given source file simultaneously. Must have conflict resolution system: what if developers make incompatible changes (e.g., changes to the same block of code)? Development tools 6 / 12
New version control (Bazaar, Git) Distributed: don t even need a central repository (though often have one). Every developer has his/her own branch. All development commits local. Completed branch can be merged to main. Or can be merged with any other developer branch. Development tools 7 / 12
Build tools and Ant Why do we need a build tool? For complex projects, compiling source code and assembling components into an application is a non-trivial task. May have non-trivial dependencies between source code files. Source code may be distributed between many directories. Compiling source code units may require specialized compiler options. With very large projects, only want to compile source code that has changed. Assembling object-/byte-code into executable may require additional steps. A build tool manages this complexity by specifying it in a build configuration file. The build tool uses the configuration file to perform build-related tasks. Development tools 8 / 12
Build tools and Ant make Build configuration file: Makefile. Makefile consists of rules, each of which consists of: Target: the name of the rule. Dependencies: targets that must be made first. Commands: commands to execute in order to build this target. Often targets and dependencies are files. Commands are shell commands. Very common for C/C++ projects. Development tools 9 / 12
Build tools and Ant A sample Makefile %.o : %.c gcc -c $@ $< myapp : a.o b.o c.o gcc -o $@ a.o b.o c.o -lm A sample invocation $ make myapp Development tools 10 / 12
Build tools and Ant Ant Not really as new school as it wants you to believe. Have tasks instead of commands. The possible tasks are defined by Ant. Ant is written in Java. Can define new tasks by writing appropriate classes and letting Ant load them dynamically. Build file is XML-based. Tasks are executed by the JVM. More common for Java projects. Development tools 11 / 12
Integrated development environments and Eclipse Why do we need an IDE? We don t! But it can sure be handy.... One-stop shopping for: Editing. Project navigation. Debugging. Version control. Build tools. Eclipse: open-source, very powerful IDE. MVC-based interface to a software project. The project is the model; the interface is a collection of views and forms; and the back-end of the IDE is the controller. Development tools 12 / 12