Community
Participate
Working Groups
The existing R4E solution is based on the storage of the review meta-data in a shared directory accessible by all team members. This solution offers a very small setup time and all users are independent to do it. However the solution above is limited to teams located under the same network. Having a centrally accessible repository is therefore needed to allow remote teams to cooperate, this accessibility shall be restricted either via SSH, usr / password, etc.. The solution discussed here requires that R4E stores its meta-data and review target files in a git repository and therefore re-use the accessibility mechanisms for remote repositories provided by git as well as the existing repository managers for it (Gerrit, Gitosis, ettc..) Using git mechanisms to access a remote repository with review data forces the simultaneous implementation of off-line reviews.
Requirements a. It shall be possible to collocate the reviews storage with existing git repos e.g. the same ones used for source code b. It shall be possible to have more than one review group per repo c. The review repo shall support storage of review target files as well as review meta-data d. R4E shall support two modes of operation i. Connected mode to a shared drive ii. Distributed with definition of remote(s)
Design Discussion There can be numerous ways to attempt the support e.g. One directory per group (no reviews branch defined), One branch per group, One branch for any number of groups within a repo. The option selected here is: One reviews branch for many possible review groups within the same repo. The advantage is to separate possible design related commits from reviews related commits. The disadvantage is: It’s not possible to see the reviews branch simultaneously with any other branches. So it can be treated as a separate repository which shall need a separate clone in order to act on reviews and source code simultaneously. This reduces the possibilities for error, as long as the clone used for reviews does not ever switch branches. The history of the reviews branch will be mixed among the different groups and reviews.
Assumptions a. Review Group folders shall not be shared with other groups i.e. one container folder per review group b. The implementation for central repository support shall have three phases: c. Phase I- Minimal R4E manipulation of git repository, the user shall be in charge to decide the configuration of the central repo. i. Collocated with another one or not ii. Repository preferences, user, password, proxies, etc.. iii. Definition of remotes iv. Use SSH or Repository managers (e.g. Gerrit, Gitosis, GitHub, etc..) v. Push (select remote, select origin and destination branches) vi. Pull/ Fetch/ Merge / Rebase, merges are expected to be trivial but in the uncommon scenario of non trivial merges, a simple decision is expected to be taken by the user (Note. Triggering an external merge tool is not yet supported by e-git) d. R4E shall use a specific branch name from a configuration file, not in preferences, to allow a uniform operation among users and manipulate review data exclusively on that branch, e. Phase II – implement a configuration wizard, R4E proxy methods to carry sequences as per configuration, support calling of an external EMF compare / merge option to resolve conflicts. Still needs a one time central repository configuration by an admin. f. Phase III – Introduce a web interface for centralised access to a dashboard, capable to associate data and statistics from multiple groups. g. This documents deals with Phase I (for techies only).
Open Issues a. EGit does not yet have support to call merge tools, for conflict resolution (we can contribute the functionality if needed) b. Merging with EMF compare sounds like the natural choice to investigate although EMF store has a compare merge which needs investigation as well. c. Phase II not planned yet. d. Pull / merge strategy will not work correctly with the current implementation in eGit/Jgit We need two different types of merge strategies i. Xml meta-data files: Although collisions shall be uncommon due to the use of user base files. When changes occur, a plain textual merge may not always be correct since the textual merge does not consider the xml syntax correctness. When a file of this type is modified on the local and remote, it shall be marked as merge conflict, in order to manually resolve the differences. ii. For Review File copies (base and target): For the review tool, the merge is not relevant since we only care about preserving an exact copy of the files under review (both base and target). So the merge strategy to use shall use the local copy as the one in the merge result. Egit’s merge strategy does not use any of the above; Jgit supports the two merge strategies above but applies the same strategy for all files. I have not yet found an optimal solution as I aim to use standard git options, I need to investigate deeper, this most likely requires changes in egit and jgit. https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372 Following the bug above: Supporting gitattributes “diff” and “merge” in jgit could help us solve the main problem. For review-meta data files we can use diff For review target files we can use “merge” *.orer merge=ours As it can be seen, this would require any file type
As of now. The solution is to use Gerrit Servers as central Repo. This will also includes the new Remotes API.
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
