GIT is a distributed version control system, this means that each developer receives a full copy of the repository, so the first think to do is to create a clone of our repository with GIT. Looking around with Google I found that this is a very simple operation:

[marco@bridge git] git svn init -s <svn.repository.url>
[marco@bridge git] git svn fetch

The first command creates a local GIT repository in the current directory and links it to the remote Subversion repository. The second command clones the Subversion repository in the local GIT repository. It may take from few minutes to several hours, depending on the size of the remote repository, but at the end we’ll have a full copy stored in the GIT repository with branches and tags:

[marco@bridge git] git branch -a
* master
  remotes/rel_1_00
  remotes/refactorings
  remotes/tags/pre_rel_1_00
  remotes/trunk

The master branch is the one linked with the remote Subversion trunk folder. Each commit done on the master branch will be sent to Subversion with:

[marco@bridge git] git svn dcommit

From time to time you also need to get the latest changes from Subversion and update your local GIT repository. Again this is a very simple operation:

[marco@bridge git] git svn rebase

Make sure you are on the master branch and that it is clean, without uncommitted changes, otherwise rebase will not work. The git stash command is very useful in this case, it allows to temporarily move away the current changes without creating a new commit.

Working on the master branch is not different than working directly on a Subversion working-copy, except you have one additional step (dcommit) to do before your changes are sent to the centralized repository. This may actually be an advantage since you can review your commits and use those nice GIT tricks like interactive rebase and amending to clean the commit history.

The main advantage to use GIT however comes with local branches, so I changed my workflow to create a local branch off of master whenever I start working on a feature, commit changes as needed to keep track of progresses, test the code, commit fixes, etc. Then when I’m satisfied I’ll merge the branch back to master and send the changes to Subversion with dcommit. Merging is where GIT shows its usefulness. A simple merge will replicate all commits from the local branch to master and consequently on Subversion, polluting the remote history with all local commits, however a merge squash will replicate all changes from the local branch without committing, this allows to do a final review of the changes, fix issues due to merging with more recent code, and commit everything as a single commit. The remote Subversion history will then be clean of all local commits and will show just a single changeset with all changes done on the local branch.

The workflow then is:

1. Create a local branch
2. Work on the local branch committing as needed
3. Switch back to master, update from remote Subversion and merge squash from the local branch
4. Review code, commit and send to Subversion

So far this GIT-Subversion workflow works fine. The development tools supporting GIT however doesn’t support the Subversion integration, so the command line tools are needed most of the times. EGit, the Eclipse GIT integration, is useful to manage the local repository but it is still immature and doesn’t offer all the options available from the command line tools. Hopefully it will offer a more complete integration in the future.

Links:

• GIT – http://git-scm.com/
• Subversion – http://subversion.apache.org/
• EGit – http://www.eclipse.org/egit/

    Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {
        public void run() {
            ULocale.setDefault(new ULocale(Platform.getNL()
                    + Platform.getNLExtensions()));
            // create the workbench instance
            Workbench workbench = new Workbench(display, advisor);
            // run the workbench event loop
            returnCode[0] = workbench.runUI();
        }
    });

JUnit allows to override the method used to run all tests defined in a class allowing us to add the code to initialize the default Realm like the above. Following are the two classes we are using to run JUnit tests against databinding-enabled classes.

JUnit 3

We wrote a DatabindingTestCase class derived from the original TestCase and overrode the run method to add the code to wrap the default realm, test case classes are then derived from DatabindingTestCase instead of TestCase.

import junit.framework.TestCase;
import junit.framework.TestResult;

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;

public class DatabindingTestCase extends TestCase {

    public DatabindingTestCase() {
    }

    public DatabindingTestCase(String name) {
        super(name);
    }

    @Override
    public void run(final TestResult result) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingTestCase.super.run(result);
            }
        });
    }

    public void testEmpty() throws Exception {
        // To keep JUnit happy
    }
}

JUnit 4

A bit more complicated because it uses annotations and test cases aren’t derived from a base class. In this case we wrote a replacement class runner DatabindingClassRunner  and overrode the run method, just like we did for JUnit 3, test case classes are then annotated with @RunWith(DatabindingClassRunner.class).

import org.eclipse.core.databinding.observable.Realm;
import org.eclipse.jface.databinding.swt.SWTObservables;
import org.eclipse.swt.widgets.Display;
import org.junit.runner.notification.RunNotifier;
import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.InitializationError;

public class DatabindingClassRunner extends BlockJUnit4ClassRunner {

    public DatabindingClassRunner(Class<?> klass) throws InitializationError {
        super(klass);
    }

    @Override
    public void run(final RunNotifier notifier) {
        Display display = Display.getDefault();
        Realm.runWithDefault(SWTObservables.getRealm(display), new Runnable() {

            @Override
            public void run() {
                DatabindingClassRunner.super.run(notifier);
            }
        });
    }
}

Links:

http://wiki.eclipse.org/index.php/JFace_Data_Binding

http://www.junit.org/

Here are few highlight of the new features found in this release:

• Jubula provides automated functional GUI testing for Java and HTML
• WindowBuilder, a popular GUI builder for Eclipse developers, is now open source and part of Indigo
• EGit 1.0 provides tight integration with the Git version control system
• Better integration with Maven, including starting Maven builds and maintaining pom files

We are very excited about this release and we are ready to develop products based on the new SDK.

More informations and downloads:

www.eclipse.org

The purpose of this blog is to publish articles about our activities and the technologies we use to develop our products, tips and tricks to make the best use of programming languages, frameworks, working tools, and various other things.

Enjoy.