for a while now, some people have been bugging me with “the git question”. They wonder why Axon uses SVN as code repository, instead of Git, which seems a better fit for community driven development. Until now, my excuse has always been “well, it’s already in svn now. It doesn’t seem like a good idea to migrate”.
But Axon is reaching a new milestone now. Axon 2.0 development is on its way, in which some major API improvements (thanks to people on this list!) are done. If there is a good time to migrate to Git (and then most likely GitHub), it is probably prior to the 2.0 release. The Google Code SVN repository will stay for a while to support Axon 1.x development.
Now here comes my question: to git, or not to git? Do you believe that migrating to Git(Hub) is an improvement? Opinions, comment, questions, remarks, etc are all welcome!
I personally use Mercurial (a.k.a. Hg) but only because I found it
before Git, and NetBeans supported Hg before Git. After downloading
the SVN version of Axon, I immediately "initialized" a Hg repository
for my own use. That said, I'm indifferent to whether a project uses
Git or Hg. I think Git is the right choice because the community is
so large and more issues/problems have been documented.
After changing the POM.xml, there shouldn't be much to migration.....I hope
thanks for you input!
Code-wise, there isn’t much to integrate. Migrating issues, documentation, downloads, etc will probably be a bit more work. But I’ll survive.
Definitely it makes collaboration and code contribution
much simpler.
In addition, I often find myself making my own git repository
out of the original one so I can customize the code for our own
projects. I use the private one myself on various machines and
others. But, every once in a while, it is necessary to pull
new changes from the original remote and merge it with our own
remote This is not possible with SVN, but with git it is simply
a matter of defining two remote reps in my local (workstation)
rep and pulling from the original, merging it with my local rep
and pushing the merged changes to our own remote rep.
One feature of SVN lacking in Git is checking out only a
folder from the remote repository and keeping it in sync
with the remote. Using Git, I'm forced to check-out the
whole repository only to work with a small fraction of
the source-code. That is why I appreciate the projects
that are partitioned into many Git repositories, glued
together using maven modules. JBoss repositories are
excellent in this sense.
On a different note, I've found the combination of
Assembla and Github yields a complete environment for
open-source projects. Scalate project is one good
example of this kind of setup.
Here is a good explanation of the high-level architecture of git: http://think-like-a-git.net/ It helped me to understand how git works. Instead of just applying my knowledge on Subversion to make assumptions about how git works.
You might already have noticed, but I’ve spent a big portion of the last few days migrating everything to GitHub. axonframework.org now redirects to the new location.
the disruptor command bus is currently an (incomplete) incubator project in the Axon Framework itself. I might give it its own repository in the future, or just a module in the framework repository. I’m not sure yet. Either way, it’s already in Git.
The disruptor itself, however, is not under my control, so that will remain in svn. I’m not planning of keeping that up-to-date all the time. But as long as they don’t publish it to a maven repository themselves, I will be publishing an Axon redistribution for it.
I do see it now under the incubator section. I think I got confused because I originally pulled the code from the branch disruptor-poc, and I was expecting a branch in github with the same name.
*Note - LMAX and Disruptor was my gateway drug for CQRS (by way of event sourcing). I am glad to see two projects that I follow coming together.
Ah, I see. I didn’t migrate it to GitHub, because it is not really under active development. I will try to fit the real implementation in the 2.0 version.
