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 ;>

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.

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

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

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.

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

Tym razem będzie naprawdę multi-testowo! Michał Gozdalik będzie prezentował możliwości testowania rozproszonego w TestNG i Selenium-Grid … w „programie” jest przewidziana demonstracja z wykorzystaniem TRZECH rzutników i komputerów … oj będzie się działo!

Dokładny plan prezentacji:

• Opis narzędzi TestNG i Selenium-Grid pod katem testowania równoległego i rozproszonego. W tej części przedstawiona zostanie część teoretyczna mająca na celu wprowadzenie w tematykę rozproszonego testowania równoległego. Wytłumaczone zostaną mechanizmy równoległe w narzędziu TestNG i Selenium-Grid
• Konfiguracja i zestawienie Selenium-Grid jako środowiska testowego. W tym punkcie przedstawiony zostanie sposób zestawienia środowiska testowego włączając konfigurację poszczególnych hostów. Stworzona zostanie macierz (Grid) trzech komputerów jako środowisko uruchomieniowe dla Selenium -Grid
• Przykładowy scenariusz testowy. Omówiony zostanie wzorzec pisania testów funkcjonalnych pod Selenium-Grid uwzględniający potrzeby częstych zmian wymagań w metodykach tworzenia oprogramowania typu Agile
• Objaśnienie kodu źródłowego testów. W tym punkcie omówione zostaną najczęściej używane części API Selenium. Wytłumaczone zostaną również wzorce poprawnej implementacji mechanizmów dynamicznych stron obsługujących technologię AJAX.
• Uruchomienie przykładu. Demonstracja działania testów na trzech komputerach i trzech rzutnikach.

Czas: 2 godziny

Miejsce: WI ZUT (PS), sala 128

Godz. 18:00

Data: 16.06.2010

Oryginalna treść zaproszenia.

Jeżeli będziesz 16 czerwca w okolicach Szczecina, nie może Ciebie zabraknąć na tej prezentacji! Taka okazja się nie powtórzy!

A tymczasem … już w ten czwartek (10.06.2010) zapraszam wszystkich na Poznań Eclipse DemoCamp, więcej informacji tutaj.

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

Testowanie, a zwłaszcza TDD jest bardzo popularnym tematem w środowisku Java’owym ale nie o samym testowaniu była mowa tylko o alternatywie dla JUnit jaką jest TestNG.

Muszę się przyznać, że z testowaniem jestem dość na bakier (ale staram się to zmienić). Po prezentacji Filipa jestem trochę przerażony ogromem możliwości TestNG. Wielokrotne powtarzanie testów, organizowanie ich w grupy, możliwość tworzenia zależności pomiędzy grupami, testowanie równoległe oraz rozproszone … i wiele więcej! Informacji była cała masa! Do tego sporo przykładów (dobrze, że będą są umieszczone na stronie JUG’a)! A wszystko to podane w dość telegraficznym skrócie … bo jak inaczej nazwać jeden przykład per feature? Ale taki był zamysł autora, żeby dać nam ogląd na całość tego ogromnego framework’a i moim zdaniem się jemu to udało!

Po całej prezentacji pozostał we mnie jakiś wewnętrzny nie dosyt spowodowany tym, że mimo jest to rewelacyjna technologia, mimo że ciągle się słyszy wkoło TDD, mimo że naprawdę jestem świadom korzyści płynących z testowania jednostkowego (i nie tylko) … to ciągle nie mogę wprowadzić w życie modelu TestFirst, trzeba będzie nad tym popracować mocno …

Ciekaw jestem czy jeszcze ktoś w tym roku będzie chciał się zaprezentować przed Szczecińskim JUG’iem … może Ty ?

Witam ponownie,

zapraszam Was w imieniu swoim i Filipa na spotkanie, które będzie poprowadzone przez właśnie niego, którego tematem będzie „Nie tylko JUnit. O TestNG słów parę a nawet kilka.”

Filus jest cudownym (bo osiągnięcie tego zakrawało na cud) absolwentemkilku etapów powszechnej edukacji, w tym Wydziału Informatyki Politechniki Szczecińskiej. Od pięciu lat zawodowo udziela się jako programista jawy, a od lat dwóch z kawałkiem próbuje swych sił także jako tester oprogramowania. Pewnie dlatego Los postawił go przed nieuchronnym spotkaniem z TestNG, a o wrażeniach z tego rendez-vous, a nawet może tête-à-tête, chętnie poplotkuje w miłych gronie szczecińskiego JUG-a.

Do wygrania licencja na jeden z wymienionych produktów firmy *JetBrains*:

a. IntelliJ IDEA Personal License
b. ReSharper Personal License
c. TeamCity Build Agent
d. Ruby Mine

oraz

licencja na agenta JVM *JRebel*.
Miejsce: WI ZUT (PS), sala 200

Godz. 18:00

Data: 22.04.2010
Serdecznie zapraszamy!

Ja będę tam na pewno, a Ty ?