Dariusz [LocK] Łuksza

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:

• migrate actual implementation of synchronization on ‘Logical Model’
• implement change sets

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

I don’t know exactly when we hit a Google Summer of Code 2010 midterm date … time runs so fast, few weeks ago I was writing that I’ve got accepted in this year’s program edition, and now we hit a midterm evaluations. This is a quite good time to sum up this short period of time.

Starting from the begging … estimating a project; now I know that initially I was very, very (and even more very, very ) optimistic about project time line. According to my initial estimation I should now start working on stashing support in JGit … but for now I’m „stuck” in synchronize view. Even more because now I see that I’ll need two or more weeks to make it ready for 0.9.0 release, now it has two major issues that I would like to solve before upcoming release. I even  don’t want to think where I would be right now if Remy didn’t made initial contribution …

OK, so what is project current status? Well we had an synchronize action and it works quite well. It shows upcoming, outgoing and conflicting changes … but there are few issues in current implementation. First of all common ancestor isn’t calculated properly (according to bug: 317371). Next issue is that we always use HEAD as a ‘local’ in three-way-compare, to be honest this seams to be an Team Framework limitation because ‘local’ is always instance of IResource .. btw. I should raise an issue for this . Last thing (for now) that in my humble opinion should be included in 0.9.0 is support for change set’s (bug: 3318473) because Git works on repository state changes not on file changes. Additionally there is one small feature that also should be included in 0.9.0: merging support from synchronization view, but (for now) it seams to be a simple thing to achieve.

What are my plans? Fix for bug 317371 currently wait for approvement in Gerrit, so I thing that this is rather a closed thing. For now I’ll focus on change set support. In case of popper handling of source branch setup I’ll wait for any hints on eclipse forum thread, then I thin that I’ll try to implement it somehow. If I fail in this task, I thing that we should disable source branch selecting and set it by default to HEAD.

Some statistics and numbers:

• Add preliminary synchronization support within Eclipse for branches. – based on Remy Suen work
  32 files changed, 2902 insertions(+), 10 deletions(-)
• Refactored UI tests
  15 files changed, 434 insertions(+), 393 deletions(-)
• Fixes strange result set in Synchronize view on Windows
  1 files changed, 26 insertions(+), 19 deletions(-)
• Fix NPE when deleting project used in Synchronize View
  1 files changed, 14 insertions(+), 8 deletions(-)
• Show repository path in Synchronize View
  4 files changed, 14 insertions(+), 6 deletions(-)
• Simplify API of GitSynchronizeData class.
  5 files changed, 33 insertions(+), 72 deletions(-)
• Prevent from NullPointerException’s
  2 files changed, 24 insertions(+), 8 deletions(-)
• Add tests for integration with Synchronize view
  13 files changed, 2249 insertions(+), 12 deletions(-)
• Fixes obtaining common ancestor in Synchronize view – wait for code review
  22 files changed, 1499 insertions(+), 1329 deletions(-)

In my humble opinion this is quite good result for around 7 weeks of work

Yesterday  patch „Add preliminary synchronization support within Eclipse for branches” (to be honest it also supports synchronization with tags) was merged into master. What it means ? This mean that every one who want to play with current Synchronization view support in EGit can easily download it from EGit’s nightly build repository.

Quick description what is supported you can find in my previous post. Of course you can play with other new features like reimplemented Git Repositories view, colorize diff and others … detailed description can be found here

Please be aware that this is only a „preliminary synchronization support„. This means that there are some things to work on and to be added in nearest feature. In case of any bugs or feature request please fill a bug report for EGit.

Since of May 16 I’m officially working on integration EGit with Synchronization View. Right now I know that this task is more complicated then I was thinking before GSoC. But thanks Remy Suen and his initial contribution to EGit which gave me some foundation this isn’t so scary as it could be . Here is a very quick overview of current situation.

Currently there are three way to launch synchronization:

1. From synchronize wizard
   Second step of wizard requires some work, it has some usability issues …
2. From branch context menu in Repositories View
   In this case we are synchronizing current HEAD (active branch), with selected branch; locally made uncommited changes are excluded in this comparison.
3. From project’s context menu by selecting Team -> Synchronize
   After this we would see above dialog:
   Where we can select source and target branch or tag (both are supported) and declare does we want include local changes in this comparison

No matter with way will you use, you always will see something similar to this:

When you will use EGit Synchronization view there are few important things that you have in mind:

1. Synchronization always occur on repository level. What it means ? It means that you cannot synchronize a single folder or file (for „file synchronization” there is a Compare With -> HEAD Revision / Git index). If you have more then one project in repository (eg. two or more maven modules), synchronize action will compare all of them.
2. Changes are organized in commits and can’t be extracted or moved between them. You can only merge entire commit.

This two things distinguish Git from CVS/SVN.

This isn’t end of my work with synchronization view. There are lots of things that should be improved, implemented and fixed eg.:

• showing proper files in Compare view (currently compare view always compares local file with remote, in some cases it should compare file that is in selected branch instead of current local)
• splitting changes into commits when we will presenting it in Synchronize view (this is important because after it would be implemented we can start thinking of implementing merging from synchronize view)
• performance improvements
• usability improvements
• (and of course) bug fixes

Yesterday Matthias Sohn, my mentor in Google Sumer of Code, ask me would I like to talk about EGit on Poznan Eclipse DemoCamp. After a moment’s reflection I’ve decided that this a great opportunity for me to get more involved in Eclipse community.

There are not much time for preparation, but I’m not a guy that prefer to have everything fixed, I’m rather prefer to improvise and let thing just happed . So I’m plan to have a quick introduction in Git, briefly describe differences between CVS/SVN and Git. Then I’ll move to describe features that we have in EGit 0.8 (that was released yesterday ). Last one but not least part would be a live demo covering some day to day use cases, describing how we, our company can benefit from distributed version control system.

btw. This would be my first public speak so I’m feeling stressed … I hope that everything went well during presentation

P.S. I’ll be speaking in Polish of course

I’ve promised you that when my patch set with tagging UI will be accepted I’ll describe all features that are implemented. Patch set were accepted and merged during GeeCON conference so that I can’t done that immediately after it happened. Now when everything back’s to normal I can present you new feature of EGit that will be available in 0.8.0 release.

Creating tag.

To create tag select ‘Team -> Tag…‘ from project’s context menu. After this you should see dialog window similar to this one:

If you start typing tag name into ‘Tag name‘ field, the ‘Existing tags‘ list will be filtered based on typed value also you are informed that this tag name already exists and you cannot create such tag:

Right now we only support creating unsigned annotated tags, so after you choose unique name for your’s new tag you must fill in ‘Tag message‘ filed with message that will be associated with this tag.

Now when you have both fields filled in you can click ‘OK‘ button (or ctrl + enter) to create tag that will be associated with current HEAD. In case if you want to associate tag with specific commit you should expand ‘Advanced‘ section (just simply click on ‘Advanced‘ text) where you can find select box that contains list of all commits. This input have special suggest feature, just start typing commit’s SHA-1 or part of first line of existing commit messages to see suggestions:

Then you can select commit that will be associated with new tag from filtered list of commits.

Editing tag.

In case of editing already existing tag (changing tag message or associated commit) you should select ‘Team -> Tag…‘ from project’s context menu. Click on tag name that should be changed in ‘Existing tag list‘ (you can also filter that list by typing in tag name into ‘Tag name‘ filed):

As you can see I’ve selected ‘v0.1′ tag. Right now ‘Tag name‘ and ‘Tag message‘ fields are disabled (also tag associated commit field in advanced section is disabled), you can enable it by selecting ‘Force replace existing tag‘.

Now you can easily change tag message and/or commit that is associated with this particular and then approve that changes by clicking on ‘OK‘ button.

Here is (I think) first screen shot of EGit tagging dialog. Right now patch set that contains it isn’t accepted but UI shouldn’t change much

After it’s be accepted I’ll describe all included features.

After yesterday’s Google announcement of accepted students it is time to move on with project because there are lots of thins to do and features lots to implement . My first task, required by Eclipse Foundation, was to create an wiki page that will describe my project … and here it is.

It is generally based on my proposal with I’ve decided to publish. I think that in next few days I’ll also publish my last year’s proposal (also accepted) for Apache Software Foundation. If you plan to take part in next Summer of Code edition those proposals could be very helpful to get an overview how it should look like

Right now I’m working on tagging support for EGit. First version of this it can is already available in Gerrit. Next version of it I’ve plan to submit before Saturday.

Na początku tego roku zastanawiałem się czy wziąć ponownie udział w Google Summer of Code … jak widać po tytule zdecydowałem się wystartować, a nawet mój projekt został zaakceptowany … YEAH! Drugi raz znalazłem się w elitarnym gronie 10001025 studentów z całego świata.

W tegorocznej edycji będę współpracował z Matthias’em Sohn’nem przy rozwoju EGita i JGita (było to do przewidzenia po moich ostatnich wpisach). Dokładniej rzecz ujmując mój projekt obejmuje integrację EGit’a z Synchronization View oraz implementację wsparcja dla schowka (git stash). W tak zwanym między czasie czyli Community Bonding Period chcę zaimplementować UI dla tworzenia tag’ów w EGit’cie, już poczyniłem nawet ku temu pierwsze kroki.

W sumie będzie to dla mnie pewna odmiana w stosunku do Web Developmentu z którym miałem do czynienia do tej pory … zapowiada się ciekawy okres, oj będzie się działo ;> ;D

BTW. W tym roku Wydział Informatyki ZUT ma wyjątkowo wyjątkowo silną reprezentaję. Z moich infromacji wynika, że do SoC zakwalifikowały się jeszcze dwie osoby:

• Tomasz Oponowicz do Apache Software Fundation
• Adam Rakowski do KDE

Nie będę ukrywał, że jestem fanem zarówno Eclipse‘a jak i Git‘a. Idealnym połączeniem obu faktów jest projekt EGit, czyli (jak by ktoś jeszcze nie wiedział albo się nie domyślał) wtyczka dodająca obsługę repozytoriów Git’a do Eclipse’a.

Jakiś czas temu opisywałem EGit’a. Wtedy to już zauważyłem brak kilku opcji w UI. Jedną z nich była np. obsługa tagowania … ale już tak nie jest (a właściwie to nie będzie), gdyż wczoraj wysłałem do Code review efekt kilku godzin mojej pracy. Jeżeli patch zostanie zaaplikowany to w najnowszej wersji EGit’a będzie można już swobodnie tagować i zmieniać nazwy tagów prosto z UI.

BTW. Nie jest to mój pierwszy patch w tym projekcie, kilka dni temu zostały zaakceptowane moje poprawki do jednej z klas w EGit’cie W zanadrzu mam jeszcze coś … ale o tym za jakiś czas dopiero ;>