Recently we have huge moments in Java oriented area in Szczecin. W had JDK7 launch party … and now we (as a Szczecin Java User Group) are organizing all day long Android workshops. More information you can found on our mailing list and registration page.
For last few days I was working on EGit Synchronize View performance, especially on Workspace presentation model (the Git Change Set is next on my list 
). My starting point was 1m 40s to compare two linux kernel versions, v2.6.36 versus v2.6.38-rc2. Such result seams to be very good, but you need to know that it was achived on SSD hard drive and comparing to regular HDD it would be much worst (maybe more then 3 or 4 minutes).
What can be improved ? Fist of all, current implementation whenever it is asked for members of particular folder it opens repository* and read data directly from it. Of course there is a cashing mechanism, but it is only on single resource level. Therefore when you are launching synchronization on repository that have about 300 folders, current implementation will create and configure 300 connections* to repository to read data and then will cache it.
So, my idea was to create only one connection*, read all data at once and put them into global cache. This cache will be used whenever any list of members for given folder will be required. This approach gives about 2.5x performance boost to synchronization (from 1m 40s down to 40s). This result looks much better and maybe on HDD this action will take less then 2 minutes … but this isn’t over
Reading members of folder is one thing, but getting information about particular file (it is changed, added or removed and does this change is incoming, outgoing or conflicting) is another. Currently we are reusing default implementation of SyncInfo class from Team Framework. This is really good implementation … when you cannot obtain such information from version control system. In Git we have SHA-1 for each file and folder version and we didn’t have to compare file contents to check they are similar or not, comparing SHA-1 is sufficient. This should save lots of CPU time, disk IO’s and developer time waiting for synchronization to finish .
Now when I already have cache that contains list of all changed resources it was natural thing to add information about change type to it. Then whenever Team Framework need to know change type it can be easily obtained from this cache … no IO’s are needed, no comparison just read from in-memory-cache and return proper value.
I’m sure that you are wondering how fast synchronization can be now … I can only that it is REALLY fast … as you can remember my stating point was 1m 40s, now same comparison will finish in less than 7s!! This means that now synchronization will be 14 times faster then before! What this means for a regular user? Well, it meas that you will get results of ‘Synchronize Workspace‘ action almost instantly.
Unfortunately, mentioned above changes are sill awaiting for review in gerrit, you can grab them from change #3891 and build it locally. I hope this will be included in 1.1 release …
* jgit uses concept of walks (with filters) through repository, but I’ve used more commonly recognized terminology here
Szczecin Java User Group is organizing a Launch Party event for JDK7. There would be a short introduction of new features in Java lanuage and API’s presented by Filip ‘Filus’ Pająk. Filip will be also speaking about Java7 syntax support in popular IDE’s like InteliJ Idea and Eclipse IDE.
As usually on ours meeting there would be drawing of licenses for JRebel and InteliJ Idea. This time we have also cool Java7 T-Shirts for all attendees.
Registration isn’t required but it would be nice if you can join this event on facebook (here you can also find mode details about this event).
I’m honored to invite every one of you to next meetup of Szczecin Java User Group. This time Kazik ‘morisil’ Pogoda will be speaking about Dependency Injection library form Google called Guice. Before getting deep into Guice he’ll explain what exactly DI is. Then we’ll dive into Guice based example application.
This is a first from a series of lectures about Dependency Injection in java by Kazik. The next one will cover Gin, dependency injection library for GWT based on Guice.
If you are interested in those topics feel free to join us 28th of April (more detailed information about time and place you can find on poster above).
Few days ago (exactly 2010-03-16) was a first anniversary of my first contribution into EGit project. Here is my very simple first patch sent into EGit’s Gerrit. It only replaces some old type loops with for-each loop, this is how it starts … Then I implement a tagging dialog, after that Google Summer of Code 2010 comes during with I was implementing Synchronization View support … and so on.
Now when I’m looking on my ohloh account I’m quite surprised with my contribution size. Currently it shows 127 commits and almost 18000 code lines changed. For me those statistics are something that I can be proud of
We’ll see what next year will bring ;>
I’m sure that when you trays automated dependency management and application building/deploying you will never want to abandon this kind of comfort that it gives. The same situation is with dependency injection; when you will get it ideas. In “normal” desktop, web, or server side project’s integrating with such tools like maven and guice isn’t that complicated like in Android projects.
Android tooling is very consistent and the ADT plug-in isn’t integrated with maven. This isn’t a problem when application is relatively small, or when you don’t want to use continuous integration tools like Hudson. But when you enter Android world from “enterprise” web application like I do, you surely would like to use CI, DI and lots more of cool stuff that was available before.
In this post I’ll present simple Android application that will have Maven and Guice support.
Read more…
Finally! I’ve implemented ChangeSet support in EGit! It looks almost the same as I was imagine it before I’ve started coding. The reality and Team API turn out much more complicated then I was thinking of it before Summer Of Code. But hours days of debugging and analyzing code of Team Framework, CVS integration plugin and “Example FileSystem” project finally give me some reasonable results. Apart from code analysis I’ve implemented four or five (I’ve published only two of them 1, 2) different approaches for this problem, all of them had some weakens and issues that latest implementation seams to solve. But now it is unimportant, the most important thing right now is to get this feature merged into EGit as fast as it is possible, another important thing is … the feature list!
Current implementation shows Git Change Set next to “normal change set”. In my humble opinion this should be changed in the feature; Git Change Set view should be set as default view for synchronization for git, because in git we track changes on repository level and cannot import only part of commit. Above Git Change Set we have node that represent repository, if we launch synchronization for more then one repository there would be more nodes on this level. Inside repository node we have list of commits that occurs between two selected points (branches of versions). Every commit is described by text label with contains first 6 characters from commit SHA-1 and first line of commit message. Commits are sorted chronologically, most recent commits are on the top. Inside commit we have list of changes that are associated with this commit. Double click action on file element will launch ChangeEditor window with will display changes that were made between two most recent commits (this one and it parent).
Here is a screenshot how it looks in real world:
It shows list of changes between current HEAD and tag v0.8.4 … from height of scrollbar in Synchronize window we can guess that upcoming 0.9.0 release will contain lots of cool new features and bug fixes ;>
Currently I didn’t manage display change direction (does it is incoming, outgoing or conflicting) I’ll work on that in nearest feature. Another think that I was unable to achieve is “proper resource handling” eg. displaying java packages as this JDT does, to be honest I don’t know that this is achievable but I’ll try … dome day . Next think is context menu and merge/commit/overwrite actions, for now didn’t even think about it, but it also should be done in nearest feature.
What is your opinion about this new feature? Maybe you see something that should be changed, removed or improved? Please, let me know … feedback is strongly appreciated!
About 48 hours ago I was describing my first small step to get ChangeSet implemented. Two days is a lots of time, and current status of this feature can be described by this screen shot:
As you can see, the “Git Change Set” appears next to the standard change set representation, this can be changed using third tool bar button (from left hand side).
Currently list of commits contains only commits between base and destination rev, the common ancestor isn’t included or even dispatched by the change set implementation (this can, or even should, be changed). Also there should be included proper graphical representations for commits, folders and files; additionally compare view should be launched when we double click on file. That things should be improved/fixed before I’ll publish code.
Beside that small issues I think that right now it is the best time to start discussion how we (yes, me and you!) would like to use this feature and have it should behave and and look. What you can see in above screen shot is only my proposition and (as always) I’m open for any suggestions and ideas. The best place for this discussion is Eclispe’s Bugzilla and bug 318473, and I encourage you to share yours opinion with us!
I’m looking forward for any feedback about this feature
BTW. One of thins that I’m proud of, in current implementation, is that I haven’t use any kind of internal API of Team Framework ;>
This is actually a really small step, because I only manage to display list of commits between two selected branches/tags (as you can see on this screen shot):
But for me it is a great success, after more then a week of fighting with Team Framework API, with was actually designed for centralized version control system.
Actually this list isn’t even sorted properly, listed commits doesn’t contains any data/child … but I think that right now things should goes faster then it was before, because I think that I’ve got idea of change set’s.
What should be done? All commit’s should be assigned to root node with should represent repository (this is in case if someone will be synchronizing multiple repositories at a same time). Commit’s should contains list of changes with proper path representation: project (if it is included in this repository), folder (and java packages if it is a java project) and finally files that was changed in this particular commit.
First step of providing synchronization feature into EGit was, display set of changes between two branches, and this works quite well (if there is applied my latest patch for common ancestor).
The next step of integration would be to make it more “git” way. In this case all changes should be spited into proper commits, because in Git we track changes on repository level (not on file level) and every commit leads us from one consistent state to another. In this case, synchronize view should show list of commits (first 4-6 characters of each SHA-1 and first line from commit message), then as a child of particular commit we should see resources that was changed by this commit. Generally all changes in particular commit should have one direction incoming or outgoing (despite conflicts that can appears on file or container level inside commit). Also merge operation should be available only on commit level.
OK, so this is how things should be handled and how they should look like … but how to achieve it?
This is quite tricky question. Thanks of bug 317934 that was made by Benjamin Muskalla I’ve started for looking information about ‘change set’ in eclipse.This leads me to ‘Team Logical Model Integration‘. According to this documentation I should almost rewrite all project … change base class of GitSynchronizationParticipant, provides implementation of IResourceMapping, ISynchornizationContext, IResourceMappingManager, etc …
The other thing that I’ve spot some time ago, is that Mercurial plug-in for Eclipse has functionally that is somehow similar with those that I’ve want to implement (they split changes into two groups: incoming and outgoing); thank god that it is open sourced . With base knowledge about ‘Eclipse Logical Model’ I’ve downloaded MercurialEclipse sources … of course using hg BTW. to download sources I was forced to create an account on javaforge.com … this is next account that I used only once … no comments for that …
When I finally get sources I’ve started inspecting how they implement change sets … and realize that they also use ‘Logical Model Integration’ … but according to comment for MercurialSynchronizeParticipant they don’t really know why they use ModelSynchronizeParticipant … why bother with that, so it is working .
So my plan for next few days is:
This looks like there will be next 1 or 2 kloc patch set o integrate into EGit …
Wish me luck … or suggest better/easier solution
Any suggestions are strongly required
follow: RSS Tweet with me