Version Control

Version Control SystemsSENG 403Tutorial 11SENG 403 Winter 2012AgendaVersion Control BasicsSubversionBasic actions in SubversionSome examples2SENG 403 Winter 2012Version Control BasicsA version (or revision) control system is able to track incremental versions of files and directories over timeThe core of a version control system is a repository

3SENG 403 Winter 2012The repository usually stores information in the form of a filesystem treea hierarchy of files and directories.

Any number of clients connect to the repository, and then read or write to these files.

By writing data, a client makes the information available to others; by reading data, the client receives information from others.3Version Control ServerThe version control server does not work just like a typical file server.The repository remembers each version of files, as they are changed in the repository.

When a client reads from the repository, it normally gets the latest version. But it can request the previous states of the file system.Working copy: A local copy of a particular version of a VCS-managed data.4SENG 403 Winter 2012The repository is kind of a file server.

There could be lots of different versions of data in the repository, but local software just know how to work on a single version. Here comes the idea of a working copy of data.

The version control client is responsible for managing the working copy and communicating changes to the server.4The Main Reasons to Have a VCS To track the various versions of digital information over timeTo enable collaborating editing and sharing of data

We want sharing but we want to avoid accidentally stepping on each others toes.5SENG 403 Winter 2012As a software development team, we need to be able to work separately, and the same time as a team on the shared resources, like source code and documentation. 5A Typical Problem

6SENG 403 Winter 2012Harrys changes are not lost, because the VCS keeps track of every version, they are absent in Sallys version of the file. 6Solution 1:Lock-Modify-Unlock

7SENG 403 Winter 2012When somebody starts editing a file, other users can only read it, and can not change it until the first one releases the lock.

ProblemsAdministrative problems: What if Harry forgets to release the lock?Unnecessary serialization: What if Harry is editing the beginning of the file and Sally wants to make a change to the end of it?False sense of security: What if Harry is working on file A and Sally is working on file B. But A and B are inter-dependent and the changes are semantically incompatible. The locking system can not prevent this.7Solution 2: Copy-Modify-Merge

8SENG 403 Winter 2012Every client has a working copy of the file.

When Harry tries to write, the server tells him that his copy of file is out-of-date, since Sally has written an edited version of that into the repository.8Solution 2 (continued)

9SENG 403 Winter 2012Harry needs to merge these changes to his working copy of the file.If his changes do not overlap with Sallys, merging is really straightforward.

Otherwise, the situation is called a conflict.

When Harry asks the client to merge the latest repository changes into his working copy, his copy is flagged as being in the state of conflict. He can see both sets of changes, and it is his call to choose one of them.

So, resolving conflicts is a manual task.

The benefit: Users can work simultaneously on the same files. They do not need to wait for each other. Conflicts are infrequent, and resolving them usually needs less time than what locking wastes. 9Subversion RepositorySubversion clients commit in an atomic fashion.After each successful commit, a new state of filesystem tree will be created. It is called a revision.

10SENG 403 Winter 2012Atomic means all or none. All the changes will apply or none of will be accepted.

Each revision is assigned a natural number. Zero is assigned to the freshly created repository which is only a root directory. After each commit of files and directory, a new revision is created with the consequent natural number.

Revisions apply to entire trees, and not individual files. Revision N means, the state of the tree after N commits.10Subversion Working CopiesA working copy is a directory on your local machine, containing a collection of files.When you finish making changes, you tell the Subversion client to publish it, so that other people can see the changes.

To manage merges and conflicts, Subversion keeps track of the revision that your working copy is based on and a timestamp recording when the local copy was last updated by the repository.11SENG 403 Winter 201211Some VCS TermsRepository (repo)Trunk/MainAddRevisionHeadCheck outCheck inChangelog/HistoryUpdate/SyncRevertBranchMergeConflictResolveDiff/Change/Delta12SENG 403 Winter 2012Repository (repo): The database storing the files. Trunk/Main: The primary location for code in the repo. Think of code as a family tree the trunk is the main line.Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.Revision: What version a file is on (v1, v2, v3, etc.).Head: The latest revision in the repo.Check out: Download a file from the repo. Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can check out the latest one.Changelog/History: A list of changes made to a file since it was created.Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files. Revert: Throw away your local changes and reload the latest version from the repository.Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (branch the code) and a noun (Which branch is it in?).Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. (At Microsoft this was called Reverse Integrate and Forward Integrate) Conflict: When pending changes to a file contradict each other (both changes cannot be applied). Resolve: Fixing the changes that contradict each other and checking in the correct version.Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.

12SVN ServerWe need a SVN server to put all the revisions of the project(s) on it.One option is to use free source code repository web sites, like SourceForge and CodePlex.In this tutorial we will use CodePlex.CodePlex supports SVN as well as MS TFS.You can define a project and use the VCS Server of the CodePlex.Warning: Unless you make the project public within a month, it will be removed after 30 days.

13SENG 403 Winter 2012Addressing the RepositorySubversion client programs use URLs to identify versioned files and directories in Subversion repositories. For the most part, these URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL:https://smntestproject.svn.codeplex.com/svn/trunk/list.txt

14SENG 403 Winter 2012SVN ClientOn Linux/Unix based operating systems, there is a command line SVN Client, called svn. On Windows, you can install GUI clients.TortoiseSVN is a free SVN client.When you install it, it will be integrated into Windows Explorer pop-up menu.

15SENG 403 Winter 201215Checkins

16SENG 403 Winter 2012The simplest scenario is checking in a file (list.txt) and modifying it over time.16Example Creating a Working Copy

17SENG 403 Winter 2012We first check out the project to have a working copy of the. Since it is a newly created project, it is empty, having no files or directories.

Then we add a file inside the working copy, name it list.txt, enter some text(Milk), and save it. Now we can commit our changes to the SVN repository.

17Checkouts and Editing

18SENG 403 Winter 2012In reality, you might not keep checking in a file. You may have to check out, edit and check in.

If you dont like your changes and want to start over, you can revert to the previous version and start again (or stop). 18Example - Commit

19SENG 403 Winter 2012Choose the working directory and select commit... From the pop-up menu.The dialog box will ask you to select files(s) that you want to check in. You can enter a checkin message as well. It would be useful later to remember what changes youve made in that revision and would help you find the source of bugs.19Basic Diffs

20SENG 403 Winter 2012The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can peel them off and apply them to a file.20Example Diff Viewer

21SENG 403 Winter 2012If you select a file in the working copy and then select Diff with previous version from the context menu, the Diff viewer will show the differences between the working copy file and the previous revision in the repository.

If the file has not been committed yet, you can select Diff to compare it with the current version in the repository.

To view Diff of two arbitrary revisions, use the Revision Log Dialog by choosing show log from the context menu. In the dialog select the revisions and then select Compare revisions21Conflicts

22SENG 403 Winter 2012Many times, the VCS can automatically merge changes to different parts of a file. Conflicts can arise when changes appear that dont gel: Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

At this point its a race: if Joe checks in first, thats the change that goes through (and Sue cant make her change). When changes overlap and contradict like this, the VCS may report a conflict and not let you check in its up to you to check in a newer version that resolves this dilemma. A few approaches:Re-apply your changes. Sync to the the latest version (r4) and re-apply your changes to this file: Add hot dog to the list that already has cheese.Override their changes with yours. Check out the latest version (r4), copy over your version, and check your version in. In effect, this removes cheese and replaces it with hot dog.

22Conflicts - ExampleCreate two working copies of the projectAdd different items at the end of list.txt.Commit the file from the first working copy.Try to commit the second copy. You will get an error.

23SENG 403 Winter 2012Conflicts Example (continued)To see the conflicts, choose SVN update from the pop-up menu, on the second working copy.It will put conflicts inside the file, and also create three more files.The conflicting area inside the file in question is marked like this> revision

24SENG 403 Winter 2012Conflicts Example (continued)Three additional files are:filename.ext.mine This is your file as it existed in your working copy before you updated your working copy - that is, without conflict markers.filename.ext.rOLDREV This is the file that was the BASE revision before you updated your working copy. That is, it the file that you checked out before you made your latest edits.filename.ext.rNEWREV This is the file that your Subversion client just received from the server when you updated your working copy. This file corresponds to the HEAD revision of the repository.

25SENG 403 Winter 2012You can compare these files to find the conflicts, or you can use the conflict editor.25Conflicts Example (continued)Open the conflict editor by choosing Edit conflicts from the menu.You should decide what the code should look like, do the necessary changes and save the file. Afterwards execute the command TortoiseSVN Resolved and commit your modifications to the repository.

26SENG 403 Winter 2012Repository StructureThere is no predefined way to organize stuff in the repository.A best practice is to use a structure like this:trunkbranches/branch1branches/branch2...tags/tag1tags/tag2...27SENG 403 Winter 2012Trunk is where you keep the current version of the project.A tag is a snapshot of the project in a certain point of time. You dont touch a tag.A branch is an independent and parallel place to work on a project. It is useful for very large and sophisticated projects.27Tagging

28SENG 403 Winter 2012In Subversion, tags are just branches that you agree not to edit; they are around for posterity, so you can see exactly what your version 1.0 release contained. Hence they end in a stub theres nowhere to go.28Tagging - ExampleSelect the folder in your working copy which you want to copy to a branch or tag, then select the command TortoiseSVN Branch/Tag.... You should change the to URL value to a new path for the tag.

29SENG 403 Winter 2012You need to have the proper structure before start to create a new tag. In this case, directory tag must be created in the repository before we create the tag.29Branching

30SENG 403 Winter 2012Branches let us copy code into a separate folder so we can monkey with it separately.

So branching isnt too tough of a concept: Pretend you copied your code into a different directory.

To create a branch you do the same as to create a tag. The difference is that, unlike a tag, you go on changing the contents of the branch.

For projects that have a large number of contributors, it's common for most people to have working copies of the trunk. Whenever someone needs to make a long-running change that is likely to disrupt the trunk, a standard procedure is to create a private branch and commit changes there until all the work is complete.

30Merging

31SENG 403 Winter 2012Where branches are used to maintain separate lines of development, at some stage you will want to merge the changes made on one branch back into the trunk, or vice versa.

In the example above, we want to add the +Rice feature to the trunk. We also want to keep all the changes that we have made to the trunk.

When you are working on separate branches, by the time you're finished with your branch, it may be near-impossible to merge your changes back into the trunk without a huge number of conflicts.

Subversion gives you the ability to selectively copy changes between branches. And when you're completely finished with your branch, your entire set of branch changes can be copied back into the trunk. In Subversion terminology, the general act of replicating changes from one branch to another is called merging, and it is performed using various invocations of the svn merge command.31Real-life example: Managing Windows Source Code

32SENG 403 Winter 2012Theres a main line with stable builds of Windows.Each group (Networking, User Interface, Media Player, etc.) has its own branch to develop new features. These are under development and less stable than main.

You develop new features in your branch and Reverse Integrate (RI) to get them into Main. Later, you Forward Integrate and to get the latest changes from Main into your branch

32References & Further ReadingsSubversion bookhttp://svnbook.red-bean.com/

TortoiseSVN Help: http://tortoisesvn.net/docs/release/TortoiseSVN_en/index.html

A Visual Guide to Version Control:http://betterexplained.com/articles/a-visual-guide-to-version-control/33SENG 403 Winter 2012