3

I need to choose a VCS to embed within a Java application I'm developing. The Java application will interact with the VCS via an API, but the user will also interact with it directly via an Eclipse plugin.

3 candidate VCS have been identified: Mercurial, Git and Subversion. I need to choose one based on the following criteria (in no particular order):

  • Java API. This is not 100% necessary, because the application could issue VCS commands via the command-line if no Java API is available. However, an API would obviously be preferable
  • Eclipse plugin
  • Simplicity. The people using the VCS (indirectly via the application or directly via Eclipse), will be software developers, but probably not the most sophisticated of the species.
  • Licensing. The license must permit to use of the VCS (in the manner described above) in a commercial application

There may be other considerations I've overlooked, I'll update the question if any more spring to mind.

Thanks!

Improve this question
4
  • 1
    do you have any license constraints, or are you working to make your application open-sourced as well? Commented Nov 30, 2010 at 10:38
  • @anrivan - Good point, I'll update! Commented Nov 30, 2010 at 10:39
  • I would add migration as a consideration. If its easy to migrate away from a solution, there is less risk in chosing it. Commented Nov 30, 2010 at 10:40
  • Suggest making this wiki given the comparison, it could be useful to others as well. Commented Nov 30, 2010 at 10:50

2 Answers 2

Reset to default
3
  • Java API: Subversion has bindings for Java, and there is some kind of reimplementation of Mercurial in Java going on (see the dev mailing list).
  • Eclipse Plugin: There are plugins that support all three for Eclipse.
  • Simplicity: Subversion arguably has a simpler model being centralised. Mercurial tends to be simpler than Git to learn and use, while otherwise being quite close in features.
  • Licensing: Git and Mercurial are GPLed, but you can invoke them via the command line with no licensing implications. Subversion uses the Apache license, which is not copyleft.

Now - why not write an interface that abstracts the differences so you can support all three? Mercurial and Git are very similar, so it should be relatively straightforward to at least support these two.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Given the fundamental design difference between Hg/Git and SVN, I reckon supporting all three would defeat the purpose of Hg and Git (distributed version control). But maybe git-svn is an option...
0

First of all, I'd scratch out Subversion unless your application has a workflow that works especially well with a centralized VCS. And even then I'd try to use Mercurial or git since svn is just so slow.

Regarding Mercurial (hg) vs Git, I personally would choose git. On one hand, hg is simpler and more intuitive, but git is much faster and has much more mindshare than hg does.

Scriptability might be an issue though. Git is really made to be scriptable from a Unix shell (although it will run on windows with some gnu software installed). Hg has a python interface, but if I recall correctly has some C extensions that will probably make it impossible to use with jython. That said, it looks like there is a third-party git library for Java: http://eclipse.org/jgit/

Regarding licensing, hg and git are both GPLed, but if you shell out to them that shouldn't be an issue. SVN uses an Apache license, so it might win on this front (basically, you can do whatever you want with it).

Improve this answer

6 Comments

I agree with the "scratch out Subversion" part. Subversion fails the simplicity requirement as soon as the working copy gets corrupted or there's a merge conflict (and those events will happen).
You scratch out subversion on criteria that have not been specified. Well done! In any case svn is not slow except for large checkouts and commits over slow network links. On the actual criteria specified svn is the only one of the three that satisfies them all.
Btw do you have numbers on the much faster part? (and the mindshare part is true only in some circles, e.g. kernel/X/ruby/freedesktop, I'm not sure it holds with windows based devs for example)
We've done pretty extensive testing on hg vs. git speed. Git is faster, but only by a small constant factor. Saying it's much faster is a bit of a stretch.
JGit is not git library, but git (re)implementation in Java. JGit is EDL (nes style BSD) licensed. Though it is not yet complete implementation (as far as I remember).
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.