Java with SVNKit to programmatically checkout and update files

Q. What is SVNKit?
A. SVNKit is an Open Source, pure Java software library for working with the Subversion version control system.

Q. What libraries are required?
A.

Use the latest version from the SVNKit website or Maven repository.

Here is the sample code:

package test;

import java.io.File;

import org.tmatesoft.svn.core.SVNDepth;
import org.tmatesoft.svn.core.SVNURL;
import org.tmatesoft.svn.core.auth.BasicAuthenticationManager;
import org.tmatesoft.svn.core.auth.ISVNAuthenticationManager;
import org.tmatesoft.svn.core.wc.SVNClientManager;
import org.tmatesoft.svn.core.wc.SVNRevision;
import org.tmatesoft.svn.core.wc.SVNUpdateClient;
import org.tmatesoft.svn.core.wc.SVNWCUtil;

public class SVNTest {
 
 private static SVNClientManager ourClientManager;

 public static void main(String[] args) throws Exception {
  SVNURL url = SVNURL.parseURIDecoded("http://svn-host/svn/myapp/artifacts/trunk/XSD/");
  ISVNAuthenticationManager authManager = new BasicAuthenticationManager("NTADMIN\\name", "pwd");
  
  ourClientManager = SVNClientManager.newInstance(SVNWCUtil.createDefaultOptions(true));
  SVNUpdateClient updateClient = ourClientManager.getUpdateClient();
  
  
  File dstPath = new File("c:\\Temp\\myapp");
  SVNRevision pegRevision = SVNRevision.HEAD;
  SVNRevision revision = SVNRevision.HEAD;
  SVNDepth depth = SVNDepth.IMMEDIATES;
  boolean allowUnversionedObstructions = true;
  
  long res = 0;
  if (new File("c:\\Temp\\wts").list().length == 0) {
   res = updateClient.doCheckout(url , dstPath , pegRevision , revision, depth , allowUnversionedObstructions );
  } else { 
   res = updateClient.doUpdate(dstPath, revision, depth, allowUnversionedObstructions, true);
  } 
 }

}

The above code is quick and dirty for familiarization with SVNKit.

Q. Where to use SVNKit?
A.

• SVNKit is widely used in different development tools like IDEs (IntelliJ IDEA, Eclipse Subversion integrations, SmartSVN, JDeveloper, etc) and SDLC tools like Atlassian JIRA and FishEye to name a few. 
• You can use it on your own home grown  automation activities relating SDLC, one off data migration tasks and batch jobs. 

Merging code with subversion, and things you must know

Branching and merging in Subversion is very common in large projects, but it has a reputation for being so difficult so that many developers either hate performing these tasks or do it incorrectly. Here are some questions and answers style tips to perform these tasks with a greater understanding.

Q. When will you merge code from a branch to trunk?
A. Merging from a branch to trunk is done

• When you’ve finished development in your branch, and 
• When you no longer need the branch.

So, only perform this merge when you are completely finished with your branch!  After merging your branch into trunk, you will no longer be able to use your branch.  In fact, you should delete your branch after merging it into trunk. If you want to add further new features, then create a new branch from your trunk.

This process of merging code from a branch to trunk is also known as "reintegrate". The diagram below shows that "Tortoise SVN" and "Eclipse SVN client" providing the initial merge options, and reintegration is one of them. You can only reintegrate a branch to trunk, after you have rebased your branch with changes in the trunk.

Q. What are the key steps involved in merging code from branch to a trunk?
A. 

Step 1: Firstly, merge trunk into your branch and commit any changes to your branch. This is a very important step as you need to make sure your branch is consistent with trunk before merging it back.

This is also known as re-basing.

You can either select a range of revisions to merge or leave it empty to merge all the revisions.

Step 2:  Commit rebased changes in your feature branch to the subversion.

Step 3: Checkout the trunk.

Step 4: Reintegrate your feature branch into trunk.

Step 5: Build and test your merged code.

Step 6: Commit the code into SVN.

Step 7: You can delete the branch.  As mentioned earlier, after merging a branch into trunk, the branch can no longer be used.  Subversion keeps track of merges using the svn:mergeinfo property.  Because of the way it uses this property, once a branch is merged into trunk it can no longer be involved in merges properly.


Tip: Copy trunk to a new branch, merge it with feature branch/s. When things done, merge the new branch back to the trunk. This technique is quite like the mercurial and git rebasing. 


Q. What do you understand by the term "working copy"?
A. It is the local copy that you had checked out. Your local working copy reflects some directory in the remote Subversion repository. For example, if you had checked out from a trunk, then trunk is your working copy, and if you had checked out from a branch, then branch is your working copy. Once you make changes to you working copy, you can commit them to the SVN. If you check your local working copy folders, you will see ".svn" folders that contain info about the SVN.

Q. What if you had made a mistake during your merge?
A. You can use the "revert" function to bring in the latest code from the SVN and overwrite your working copy. This means, undoing your uncommitted changes.

You can also switch between branches and trunk.

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.