Version Control. Luka Milovanov

Transcription

1 Version Control Luka Milovanov

2 Configuration Management Configuration management is the management of system change to software products Version management: consistent scheme of version identification System building (assembling components into a system) Change management: configuration data base records information about changes and change requests System releases include executable code, data, configuration files and documentation CASE tools are available to support all CM activities (stand-alone and integrated systems)

3 CASE Tools for Configuration Management Versioning RCS (Revision Control System) CVS (Concurrent Version Control) Subversion Build Shell scripts, make, ant Change Management Bug database, change tracking Release Management Feature tracking, rpm (build packages) Configuration management = Version + Change + Build +Release Rational ClearCase SourceForge

4 Version Control Discipline of managing the evolution of software Key element for moving from initial (undefined process) to repeatable (project management) stages in software systems development Keep track of the evolution of software When was a change made? Why was it made? What exactly was changed? Make it possible (easier) to try out new parts and revert bad changes A collaboration tool for multiple developers

5 How? Usually by having special software that aids in version control The software keeps different versions in a repository The developer checks out the program onto his computer This workspace acts as the place where changes to the program can be made Finally, the changes are committed to the repository

6 Repository A shared database for engineered artifacts Avoids: Overwriting one developer's changes by someone else Forgetting what changes were made in an earlier version Advantages: Freeing developer's creativity since it's easy to revert back to any change if something went wrong Tracking and remembering any change Quite transparent in the development process

7 Repository, cont. Additional features Bug-tracking systems, patch managers, mailing lists Allows queries about configurations to be answered Who has a particular system version? What platform is required for a particular version? What versions are affected by a change to component X? How many reported faults in version T? Operations Check out (import) Obtain an existing version of an item from the database Check in (commit) Add new version of an item into the database It is not possible to modify existing items in the database. You need to create a new version

8 Version Derivation Structure The repository The repository's filesystem Imagine an array of revision numbers, starting at 0, stretching from left to right Each revision number has a filesystem tree hanging below it Each tree is a snapshot of the way the repository looked after each commit.

9 Basic Operations Checkout Add a file (or directory, symlink etc..) Remove a file Rename a file Committing changes Retaining previous versions

10 Subversion A better CVS Centralized server Supports file renaming (unlike CVS) Changes are in fact atomic (unlike CVS) Supports arbitrary tagging of files using named properties Example: the svn:ignore property of a directory tells which files to ignore (e.g. temporary object files)

11 SVN Revision Numbers Subversion's revision numbers apply to entire trees, not individual files Each revision number selects an entire tree, a particular state of the repository after some committed change Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit When a Subversion user talks about revision 5 of foo.c, they really mean foo.c as it appears in revision 5. Notice that in general, revisions N and M of a file do not necessarily differ!

12 Checkout svn checkout checks out the Luka s course assignment Every directory has a special.svn directory containing metadata about the project

13 Basic Work Cycle 1. Update your working copy svn update 2. Make changes svn add svn delete svn copy svn move 3. Examine your changes svn status svn diff svn revert 4. Merge others'changes svn merge svn resolved 5. Commit your changes svn commit! If you are not adding new files, but only modifying the existing ones, you only need 2 commands: svn update and svn commit Examining History svn log Shows you broad information: log messages attached to revisions, and which paths changed in each revision svn diff Shows you the specific details of how a file changed over time svn cat This is used to retrieve any file as it existed in a particular revision number and display it on your screen svn list Displays the files in a directory for any given revision Other Useful Commands svn cleanup If Subversion ever tells you that some part of your working copy is locked, then this is the command that you should run svn import a quick way to copy an unversioned tree of files into a repository, creating intermediate directories as necessary

14 When to Commit Preferably: One idea One commit When substantial work has been made (your own computer's harddisk might not be backuped) Checkpointing the current code so you can try different additions Don't mix several different changes Harder to understand what parts of the change are connected Individual parts in a change are harder to revert

15 Tags Tags are explicitely named snapshots of the project. Useful for making an external release so that you remember exactly what you have shipped Tag your solutions (next slide) In general: bug reports from customers are then analyzed by checking out the specific tag In subversion, this is done by copying, e.g. svn cp myproject tags/0.1

16 Directories myproject Your Repository Layout In Subversion myproject/trunk for files and unit tests myproject/solutionn for the solutions Solutions: tag when done svn copy \ \ -m Assignment 1 completed

17 Subclipse

18 Adding a project to version control

19

20 Subclipse, checkout from repository 2 1

21 Subclipse, cont

22