Branching is a powerful tool in managing development and releases using a version control system. A branch produces a split in the code stream.

One recurring debate over the years is what goes on the trunk (main baseline) and what goes on the branch. How do you decide what work will happen on the trunk, and what will happen on the branch?

Here is my rule:

Branch rarely and branch as late as possible. .i.e. Branch only when its absolutely necessary.

You should branch whenever you cannot pursue and record two development efforts in one branch. The purpose of branching is to isolate development effort. Using a branch is always more involved than using the trunk, so the trunk should be used in majority of the cases, while the branch should be used in rare cases.

According to Ned, historically there were two branch types which solved most development problems:

• Fixes Branch: while feature work continues on the trunk, a fixes branch is created to hold the fixes to the latest shipped version of the software. This allows you to fix problems without having to wait for the latest crop of features to be finished and stabilized.
• Feature Branch: if a particular feature is disruptive enough or speculative enough that you don’t want the entire development team to have to suffer through its early stages, you can create a branch on which to do the work.

Continuous Delivery (and deployment) goes one step further and solves hard development problems and in the process avoiding the need for branching.

What are the problems with branching?

• Effort, Time and Cognitive overhead taken to merge code can be actually significant. The later we merge the worse it gets.
• Potential amount of rework and bugs introduced during the merging process is high
• Cannot dynamically create a CI build for each branch, hence lack of feedback
• Instead of making small, safe and testable changes to the code base, it encourages developers to make big bang, unsafe changes

P.S: I this blog, I’m mostly focusing on Client-Server (centralized) version control system. Distributed VCS (DVCS) have a very different working model.

Today, I wanted to move a SVN repository from my windows laptop to my Mac. So I was trying to dump the SVN repository from Windows machine and load it on my Mac. I was accessing my SVN repository via an URL (svn://machine_ip) instead of a Path (file://machine_ip)

Unfortunately svnadmin dump seems to accept only file paths:

svnadmin dump svn://localhost/project_name > project_name.svn_dump
svn: ‘svn://localhost/project_name’ is an url when it should be a path

Luckily I remembered the location of the repository on the file system. So then I tried the following and it worked

svnadmin dump /users/naresh/local_svn_repos > project_name.svn_dump

Please note that the local_svn_repo folder must be the actual root of your svn repository. This folder usually contains the following folders:

• format (file)
• conf
• db
• hooks
• locks

Currently I’m working on adding Revision Control support to FitNesse. In the process, I’m creating a SVN adapter using svnkit library.

Once I’ve added a file, if I try to commit the file using

1
2
3
4
5
6

protected void commit(File file) throws SVNException {
final SVNClientManager manager = SVNClientManager.newInstance();
final SVNCommitClient commitClient = manager.getCommitClient();
final File[] filesToCommit = new File[] { file };
commitClient.doCommit(filesToCommit, false, "Auto Commit", false, false);
}

I get the following exception:

1
2
3
4
5

svn: Unable to open an ra_local session to URL
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:55)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:40)
at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:582)
at org.tmatesoft.svn.core.wc.SVNCommitClient.doCommit(SVNCommitClient.java:549)

Trying to Google for this, did not take me anywhere. Finally after debugging thru svnkit’s code, I stumbled upon the following line which throws the exception:

1

SVNRepository repository = SVNRepositoryFactory.create(SVNURL.parseURIDecoded(url));

Basically, they have SVNRepositoryFactory class which expects the client to register an appropriate driver to handle the given protocol. Their javadocs says:

Depending on what protocol a user exactly would like to use to access the repository he should first of all set up an appropriate extension of this factory. So, if the user is going to work with the repository via the custom svn-protocol (or svn+xxx) he initially calls

1	SVNRepositoryFactoryImpl.setup();

More details: http://svnkit.com/kb/javadoc/org/tmatesoft/svn/core/io/SVNRepositoryFactory.html

Solution: Since I’m using File System (file://) protocol, I had to add the following line in a static block of my adapter class:

1

FSRepositoryFactory.setup();