Post Category → archive

Progress on non-workspace files in Workspace presentation model

For last three weeks I was working on including non-workspace files in Workspace presentation model in Synchronize View. This idea can sounds weird since the Workspace presentation model was designed to show only changed files that are in Eclipse workspace … but there are some use cases in which such behavior seams to be reasonable (eg. EGit and JGit projects doesn’t import repository root into workspace only projects are imported and files like master pom.xml, README, LICENCE and so on are left outside workspace).

If you don’t import all data into Eclipse workspace you won’t see any incoming nor outgoing changes. Even more, after merge/rebase actions changes in non-workspace files will magically appear in those resources and can even brake something (eg. massed up in master pom.xml file).

So, what is current status ? First of all I want to point that I’m describing here current situation in my working copy, described here changes currently are not available in public. After hours of debugging, code analysis and rewriting my code I’ve manage to show some indication in synchornize view that there are some non-workspace chagnes. The next step will be to show what particular file was changed and then enable all operations like overwrite, mark as merged, etc.

Here is a screenshot showing current status:

Non-workspace files in Workspace presenation model
As you can see there is home folder in sync results. It even have expand indicator (but after expanding it there is nothing inside). I suppose that on windows this folder will correspond to drive letter, but I’m not sure here.  Now I only need to tell Team Framework that there are some files inside home node …

This seams to be quite easy task, since parent folder is already included in view … but this isn’t that easy. First of all Workspace model is based on IResource‘s with are manageable by Eclipse platform. Of course I can create such resource using IWorkspaceRoot.getFolder() and IWorkspaceRoot.getFile(). Unfortunately non-workspace resources created by those two methods will return theirs first segment (on unix system it will be usually /home) as theirs project. Of course such project doesn’t exist in workspace therefore this node is empty.

Honestly speaking I currently don’t have any good ides how to move things forward … as usually I’ll dive into debugging and code analysis …

Any hints and ideas from the community are kindly welcome!

Huge performance boost for EGit sync-view

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

Java7 Launch Party @Szczecin

Java7 T-Shirt frontJava7 T-Shirt backSzczecin 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).

Drag-and-Drop staging/un-staging in Git Change Set model

The EGit 1.0 will be officially released in upcoming days, but I’ve already started to working on version 1.1. Today I would like to demonstrate you a feature that I was recently working on. To be honest the main idea of this functionality comes from my GSoC 2010 proposal, but I didn’t manage to implement it … until now ;), so what it is?

The post title should told you everything about it … but (if not) I’ve also prepared a screencast that is embedded above where you can clearly see how it works in real environment.

I know that in version 1.0 the Staging view was introduced, to be honest, I don’t think that separate view for staging is really needed. But I don’t have anything against it, it looks cool and works properly ;). Also I don’t see anything bad with having this functionality doubled in Git Change Set model and give users possibility to choose between both of them.

I’ve pushed this feature (and all dependent changes) yesterday. This is quite huge change so I think that we’ll iterate few times with it before it will be merged into master, but I hope it will be included in 1.1.

As always feel free to share any ideas and comments!