Concepts of Version Control

1. Concepts of Version Control A Technology-Independent View

2. Topics • We’ll discuss basic version control concepts including: • What version is and why we care • Repositories and archives • Checking in and check out archives • Reporting on archives • Branching and merging archives • Security

3. What is Version Control? • Over time files evolve and change. • Tracking these changes can be difficult, since the changes stem from different project teams. • Version control allows users to maintain the integrity of files that are subject to change.

4. Why Do We Care? • Version control systems provide users the ability to serialize changes to a given file. • Most such systems also allow users to revert to an earlier form of a file. • Anything can be stored under a good version control system including source code, documents, images, and binaries.

5. Common Version Control Software • Some common software for version control includes: • PVCS • Microsoft Visual SourceSafe • CVS / RCS

6. Version Control Basics • Although there are many version control systems on the market, most provide the same basic features. • This section describes some of those features.

7. Repository • All version control systems work based on a repository. • The repository holds a copy of each file under control of the version control system. • The repository generally maintains an initial copy of each file along with a log of all subsequent changes made to that file.

8. Adding Files to the Repository • Not all of the files on your system are automatically version controlled when a version control system is installed. • To “version” a file, you must explicitly place that file into the repository. • A file under control of the version control software is commonly called an archive.

9. Checking Out Archives From the Repository • Once a file has been placed under revision control, you must check it out of the repository in order to change it. • This ensures that one user doesn’t inadvertently overwrite the changes made by another user. • This is called checking out an archive.

10. Checking Out Archives From the Repository • Every version control system is essentially a library with each archive a book. • At any given time, one and only person can have possession of a book. • In version control systems, only the user with possession of an archive can change that archive. • It is also possible to check out read-only copies of archives.

11. Checking In Files to the Repository • Once you have an archive checked out, you can make changes to it. • Once you have completed the changes, it must be checked back into the repository so that it is again available to the other users of the version control system. • This is called checking in an archive.

12. Unlocking a Revision • Sometimes we check out an archive intending to make changes to it, but then discover we don’t really have to. • We don’t want to check in an archive that hasn’t changed. • Most version control systems provide the ability to unlock a checked out archive without actually checking it in.

13. Revisions • When you save your changes using a version control system, the new version of the archive is given a new revision number. • It isn’t necessary to know how the revision numbers are generated (it’s a form of magic), but you should know that they represent the changes in an archive over time.

14. Checking Out Archives by Revision • Sometimes we want to check out an archive by a specific revision number. • This is useful if we need to revert to an earlier code base in order to diagnose a bug. • Be careful! If you make changes to earlier revision of an archive and check it back in, you lose all of the changes in the later revisions of that archive.

15. Repository Utilities • Most version control systems provide one or more of the following utilities: • Reports on an archive’s revision history • Reports on the differences between two revisions of an archive • Branching and merging • Security

16. Report on Revision History • A report on revision history generally tells you, by revision, what changes were made to an archive. • This depends on the person making the changes to add comments to the archive when it is checked in. • Always do this!

17. Report on Differences Between Two Revisions • A report on differences is essentially a sophisticated comparison algorithm. • It attempts to determine where lines have been added to, changed, or removed from one revision when compared to another. • It is not always precise, but for source code it can be useful for determining what changed between the revisions.

18. Branching and Merging • Sometimes multiple development teams need access to the same archives for different purposes. • One team might be responsible for maintenance and bug fixes while another is responsible for new development and enhancements. • We need a way to allow these teams to co-exist without stepping on one another’s code base.

19. Branching • Branching allows us to create two different revisions from a single, common, root archive. • Each team could thus make its changes independently to its own branch of the root. • This is dangerous!

20. Merging • At some point, we’ll need to combine the branched revisions of the archive. • This is common with a new release of a product; we need to merge the bug fixes with the new features. • Modern version control systems allow us to merge branches back into a single revision. • This often requires human intervention.

21. Security • We often define basic security on our repository including: • The users who can access the repository • The abilities of that the users can exercise on the archives • Different projects with their own repositories, might not allow developers from other projects access to their archives.

22. Review • We’ve discussed basic version control concepts including: • What version is and why we care • Repositories and archives • Checking in and check out archives • Reporting on archives • Branching and merging archives • Security