2. MergeA version control system like Subversion allows the members of a group project to work on different branches of the project. The good news is that they can work on the project at the same time without interfering with each other, but the downside is that the changes made by each member are not automatically shared by others. This is where the merge operation comes in, which, in a sense, copies changes between different branches of a project. In this section, we first explain the semantics of the merge operation in Subversion, then discuss several merge scenarios that are common in a group project setting. 2.1 The Semantics of Merge in SubversionThe merge operation in Subversion take two parameters, a Source URL (a.k.a From URL or Start URL), and a Target URL (a.k.a. To URL or End URL):
The semantics of the merge operation is the following: Compare the version of the project represented by the source URL and the version represented by the Target URL, calculate the changes needed to transform the source version to the target version, and apply these changes to the working copy. There are several things worth noting here. First of all, when people look at terms like Source URL and Target URL, they tend to think that the changes come from the source version and will be copied to the target version. However, in Subversion it is actually the opposite - the target version has the changes the source version wants. The terms source and target (or from and to) refer to the states of the project before and after the changes are applied, not the source and the target of the changes themselves. Secondly, note that the changes (i.e. differences) bwteeen the source and the target version are applied to the working copy, not the branch in the repository. In other words, nothing changes in the repository after a merge until you perform a commit operation. Thirdly, a URL in Subversion is the combination of a repository location and a revision number. When the revision number is not specified, by default it is assumed to be the latest revision at the repository location, which is known as the HEAD revision. Sometimes you might want to extract the changes between two revisions at the same repository locations, and in those case you must specify the revision number explicitly, for example:
In this example Subversion would extract the changes between Revision 3 and Revision 2 at the repository location svn://cs3/hello/branches/StudentA-branch and apply these changes to the working copy. 2.2. Preparation Before MergeMerge can be a little tricky, and to make the process as smooth as possible, a little preparation before merge is recommended. First, commit all local changes and make sure the working copy is up to date. Specifically, if the working copy has local changes, perform a commit operation; if the working copy has no local changes, perform an update operation.
Second, take a look at the changes to be merged before doing the merge. For example, suppose Student A made some changes to the
Figure 2.2.1 Revision History of Student A's Branch
The revision history shows the list revisions at the repository location /branches/StudentA-branch. Selecting a revision in the list will reveal further details about the revision. For example, when Revision 5 is A screen capture video illustrating this process is available here. 2.3 Common Merge Scenarios |