Ingeniørh. Version Control also known as Configuration Management

Transcription

1 Ingeniørh rhøjskolen i Århus Version Control also known as Configuration Management

2 Why version control? Teamwork You work in a team. You open a file and start work on it. Your colleague opens a file and starts working on it. You save your version, satisfied with your work. You shut down your machine and go home. Your colleague saves her version. Only it happened to be her version of the file you just saved your version of before going home. Your version has just disappeared into nothing. You were quite satisfied with something that no longer exists. If you have a version control system, when you start work on a file, it can be locked so your colleague cannot make changes at the same time. Or if your colleague saves a version, you'll know about it. And you'll still be able to get the previous version back. Slide 2

3 Clients Why version control? 1. You just spent several weeks on a that version of your client's website and present it to him. 2. And your client is not happy. 3. Could we go back to the previous one, please and restart from there? 4. If you regularly make backups, all the files are still there - somewhere... But which files on which backups? 5. How do you put it all together again? If you have a version control system, you can simply check out the previous version of your whole project and start over. Slide 3

4 The Lock-Modify-Unlock Solution Many version control systems use a lock-modify-unlock model to address this problem. In such a system, the repository allows only one person to change a file at a time. A user must "lock" the file before he can begin making changes to it this is often named check-out a file. All other users are prohibit from making changes to the file until it is checked-in again. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. The problem with the lock-modify-unlock model is that it's a bit restrictive, and often becomes a roadblock for users! Slide 4

5 The Copy-Modify-Merge Solution In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly. Slide 5

6 Merge conflicts But what if Sally's changes do overlap with Harry's changes? What then? This situation is called a conflict, and it's usually not much of a problem. When Harry asks his client to merge the latest repository changes into his working copy, his copy of file A is somehow flagged as being in a state of conflict: he'll be able to see both sets of conflicting changes, and manually choose between them. Note that software can't automatically resolve conflicts; only humans are capable of understanding and making the necessary intelligent choices. Once Harry has manually resolved the overlapping changes (perhaps by discussing the conflict with Sally!), he can safely save the merged file back to the repository. Slide 6

7 Chaos? The copy-modify-merge model may sound a bit chaotic, but in practice, it runs extremely smoothly. Users can work in parallel, never waiting for one another. When they work on the same files, it turns out that most of their concurrent changes don't overlap at all; conflicts are infrequent. And the amount of time it takes to resolve conflicts is far less than the time lost by a locking system. There is one common situation where the lock-modifyunlock model comes out better, and that is where you have un-mergeable files. For example if your repository contains some graphic images, and two people change the image at the same time, there is no way for those changes to be merged together. Slide 7

8 Subversion IHA runs a Subversion Server (SVN) which is free to use for students at IHA. To use the server: 1. Create a repository for the project 2. Create the directory layout for the top level in the repository 3. Import the initial version into the repository 4. Check-out the initial version and start to modify the files The files you check-out is your working copy (WC) 5. Send your changes to the repository (Commit) Before you commit you should first update your WC Subversion uses the copy-modify-merge solution by default, and in many cases this is all you will ever need. However, as of Version 1.2, Subversion also supports file locking, so if you have unmergeable files use locking. Slide 8

9 The Client To interact with the server you need a client. There are many different clients for SVN, but IHA recommends TortoiseSVN. TortoiseSVN is a Windows shell extension, and can be used with all kind of files. The installer (msi-package) for TortoiseSVN can be found on the Common file share: K:\from_eit_staff to eit_stud\tortoisesvn or downloaded from: (here you will find the latest version) On the Internet you can also find SVN clients that integrate nicely with Visual Studio or Eclipse. (se the Clients and plugins section) Slide 9

10 The Repositories For each group in I3PRJ3 there is a repository at the IHA SVN server at the address: (for group 1, for group 2 the last digit is 2 etc.) Slide 10