Posts Tagged → synchronize view

Preview of EGit integration with Synchronization View

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 😉