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!
Mimo, ze oficjalne ogłoszenie wyników GSoC09 odbyło się prawie dwa miesiące temu, dla mnie google’owe lato z kodowaniem zakończyło się dopiero parę dni temu kiedy to kurier dostarczył do mnie paczkę z koszulka i certyfikatem.
Co do samego projektu, to niestety nie udało mi się go skończyć w wyznaczonym terminie. Osobiście stopień zaawansowania oceniam na 75-80%. Mimo to Reinhard (mój mentor) uznał, że wykonałem na tyle dobrą pracę że ukończyłem pozytywnie GSoC.
Koniec Summer of Code nie oznacza dla mnie końca współpracy z developerami Cocoon’a, zwłaszcza, że nie wykonałem w pełni stawianych sobie celów. Dodatkowo na horyzoncie pojawiły się nowe interesujące pomysły na rozwój modułu monitorującego trzecią wersję Cocoon‘a.
Ostatnio pisząc o Summer of Code wspominałem o artykule traktującym o Spring JMX, miał on się ukazać w ciągu 2-3 tygodni … cóż nie udało się ale nie wydaje mi się by jego los był przesądzony . Wszystko jest ciągle kwestią czasu … jest to jedna z rzeczy którą chciałem zrealizować w czasie GSoC i ciągle pozostaje na mojej (dość, długiej(sic!) już) liście TODO.
EDIT:
Zapomniałem o jednej bardzo ważnej rzeczy … 90% napisanego przeze mnie kodu podczas GSoC znajduje się już w repozytorium ASF, a dokładniej mówiąc to jest tutaj. Natomiast całość kodu dostępna jest w archiwum znajdującym się pod koniec tej listy.
Cóż ostatnie dwa miesiące były dla mnie dość wyczerpujące … praca, studia i summer of code nie pozostawiały mi zbyt wiele czasu i energii na udzielanie się tutaj. Na szczęście wszystko jak na razie idzie bardzo dobrze … może z wyjątkiem studiów bo czeka mnie jeszcze (średnio przyjemna) batalia wrześniowa …
Na chwilę obecną mogę odłożyć sobie studia na półkę i zająć się przyjemniejszymi rzeczami . Właśnie kończę implementować (a właściwie to dokumentować (sic!) już powstały kod) drugi z zaplanowanych czterech milesone’ów w projekcie Cocoon 3 monitoring, tak więc połowa mojego projektu zbiega się praktycznie idealnie z połową summer of code.
Na chwilę obecną mogę uchylić rąbka tajemnicy odnośnie kolejnego posta … będzie on dotyczył dynamicznej rejestracji MBean’ów oraz dynamicznego wymuszenia ich „hierarchizacji” z wykorzystaniem Spring JMX (brzmi tajemniczo, zwłaszcza druga część ). Mam nadzieje, że uda mi się zebrać w sobie i w przeciągu najbliższego tygodnia (… no może dwóch) opublikować ten wpis
Konia z rzędem temu kto potrafi zmusić GIT’a do generowania patch’y kompatybilnych z SVN’em (a zwłaszcza z TortoiseSVN) !
Jeżeli nie uda się mi zmusić GIT’a do tego żeby wygenerował patch’e zgodne z SVN niestety będę musiał zakończyć w Summer of Code ’09 przygodę z GIT’em … na prawdę będzie mi z tego powodu przykro 
Najpierw przygotowania, potem dwa tygodnie nerwów oraz oczekiwania … i oto są wyniki tegorocznej edycji Google Summer of Code … w którym będe brał udział jako student w Apache Software Fundation;>
W ciągu tych paru miesięcy będę implementował system monitoringu dla Cocoon’a 3 pod opieką Reinhard’a Poetz’a … wow, no nie mogę uwierzyć, będzie się działo ;D
