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 😉
Pingback: Tweets that mention Dariusz Luksza: EGit synchornization – the next step -- Topsy.com
Hi Dariusz,
as the author of the sync view integration for MercurialEclipse I can only suggest you NOT to use our (my) code, as this is just crap which SOMEHOW works. Ok, it works, but I do not like the code and there are also many limitations and bad side effects.
I’m not proud to be author of this code. I found it VERY complicated to write changesets support for the sync view without real understanding of the model/API behind. I didn’t understood it simply because there is / was no proper documentation / examples, and the existing CVS/SVN plugins code is also not a big help, at least for the (limited) time I had.
Additionally, after the implementing some things I found that IF I would follow some of the code examples, the overall performance would be exceptionally bad. The team API was designed around centralized VCS, and it simply doesn’t fit for the DVCS case.
As you have mentors from the Eclipse core team, I would push them to provide a clear advice/example HOW the team API is supposed to work with the DVCS changesets model, and if there are cleaner (clean) way to write DVCS sync view integration as I did it for the MercurialEclipse.
Good luck, and I hope you will do a better job, so that we can reuse *your* code in MercurialEclipse.
Regards,
Andrei Loskutov
Hi Darius,
I think the comment from Andrei is a little understatement.
Our goal was to implement the sync view 1) for medium size teams/projects 2) to reach a quality to be able to use in production 3) get more feedback for the future direction from the community.
We use the sync view in production with others, and captured the feedback from our team for future directions. There are plenty of ways to make it better, we are glad to work with together on this.
Janos
—
anos Koppany
_________________________
Follow @intland on Twitter: http://twitter.com/intland
Intland Software GmbH
Curiestr. 4
D-70563 Stuttgart, Germany
Phone: +49-711-67400-678
Fax: +49-711-67400-686
e-mail: j.koppany@intland.com
@Andrei Loskutov
Thank you for this frank assessment. I’ll try to get support from core team developers and I’ll do my best to implement synchronization in EGit the best I can. Once again thanks for yours feedback 😉
@Janos Koppany
I believe that truth is somewhere in the middle, as usually ;). You write that you (as a community of developers) manage to establish feedback loop with users, so in my humble opinion now it is a time to use it and make MercurialEclipse better and cooperate. 😉
Thank you for yours comment 😉