Source control system and subversion (aka SVN) questions and answers

Q. Why do you need a source control system?
A. Source Control systems like subversion is a must if you are writing Java code by yourself or as a team. It allows multiple streams of coding, tracks the changes in your code and allows you to roll back to previous versions.  Here are the benefits of a source control system.

• Have you ever realized that you have made a mistake and wanted to revert back to your previous revision? You also don't lose your code. You can experiment with things., and if things don't work as expected, you can revert your code.
• Multiple streams or projects can work simultaneously on the same code base by branching the code from trunk, and then merging the code back to trunk and then tagging it prior to releasing and deploying the code.
• Versioning helps you look at previous versions of the code to find out when and where bugs were introduced. You can compare two different versions of code side by side.
• You can also create patches and apply patches.

Q. What are the differences between trunk, branch, and a tag in relation to a source control system like SVN?
A. There are many source control systems like Git, Clearcase, Subversion (aka SVN), etc, and SVN is a very popular open source source control system. You can use it via its command line commands or via GUI based client tools like TortosieSVN.

• A trunk in SVN is main development area, where major development happens. Like a tree, trunk is a tree’s central superstructure. All branches come out of the trunk.
• A branch in SVN is sub development area where parallel development on different features happens. Branches are created for adding new features/enhancements, bug fixes, and maintenance. After completion of a functionality, a branch is usually merged back into trunk. Tools like TortoiseSVN and IDE plugins for SVN simplifies the code merging task.
• A tag in SVN is a read only copy of source code from branch or trunk at any point of time. A tag is mostly used to create a copy of released source code so that it can be rolled back.
• A head is the latest version in the repository. That is either in the trunk or branch.

Q. What are the basic steps involved in merging? for example from a branch to trunk.
A. 

• Step 1: Check out the destination stream from SVN. In this case it is the trunk.
• Step 2: The SVN client tools like tortoiseSVN or Eclipse IDE plugin provides you with a GUI interface to select the source code to merge. In this case it is the branch. Click on the merge button to merge automatically, and where there are conflicts, you need to merge those conflicts manually. You can also use the SVN command-line option.
• Step 3: Test the merged code locally to ensure that they compile and work as expected.
• Step 4: Check in the merged code into the destination. In this case the trunk.

Q. What do you understand by the term rebase?
A. When developers work in parallel and commit changes to different streams of the same code base, eventually some or all of these commits have to be brought together into a shared graph, and merging and rebasing are two primary ways that let us do that.

• Merging brings two lines of development together while preserving the ancestry of each commit history. It is like melting two different pipes  together. The pipe itself doesn’t break, it’s just combined with another pipe. So, the commit itself knows that it is a merge commit.
• In contrast, rebasing  is like cutting off a pipe and weld it on another pipe. Rebasing unifies the lines of development by re-writing changes from the source branch so that they appear as children of the destination branch – effectively pretending that those commits were written on top of the destination branch all along.

Q. What is a sync merge and when do you perform it?
A. Say you create a new branch from a head to work some enhancements, and simultaneously some bug fixes were made on the trunk. Suppose that a month has passed since you started working on your new branch and your new feature are not finished yet, but at the same time you know that other people on your team continue to make important bug fixes on the trunk. It's in your best interest to replicate those changes to your own branch, just to make sure that they integrate well with your changes. This is done by performing a sync merge, which is a merge operation designed to bring your branch up to date with any changes made to its ancestral parent, which is the trunk in this case. The sync merge is also known as rebasing.

Q. What do you understand by the term patch or pull request?
A.A patch means change sets you want to communicate and apply to another repository. Nowadays, the GitHub pull request makes it really easy to apply patches on GitHub repos, which is useful when you aren't a direct contributor. A patch is a small file that indicates what was changed in a repository. It's generally used when someone from outside your team has read-only access but had a good code change available. He then creates a patch and sends it to you. You apply it and push it to the git repository. Here is a simple example.

Create an input file named "input.txt" as shown below and check in to the repository like SVN.

  
This is line A.
This is line B.

Now modify the above code as shown below by replacing A in first line to C.

  
This is line C.
This is line B.

Now create a patch file, for example from eclipse IDE using the SVN plugin by right clicking on the file and then select Team --> Create patch. The patch file created will be

  

Index: src/test/resources/input.txt
===================================================================
--- src/test/resources/input.txt (revision 19063)
+++ src/test/resources/input.txt (working copy)
@@ -1,2 +1,2 @@
-This is line A.
+This is line C.
 This is line B.
\ No newline at end of file

The above patch tells that

@@ -1,2 +1,2 @@ tells that in line 1 was removed and another line 1 was added and line 2 remains the same. The "-" next to "-This is line A." indicates that this line was removed. The "+" sign next to "+This is line C." indicates that this line was added. You will also get similar patch output with a Unix diff tool.

 
$ diff -u input.txt output.txt 

Note: For beginners, it can be a bit overwhelming to understand version control system, and the following blog explains things visually.