Last updated by bradfordcp@drup... on Tue, 2009-07-21 15:16
Project information
Project page on drupal.org: http://drupal.org/project/conflict_resolver
Student: Christopher Bradford (bradfordcp on d.o, bradfordcp@drupal.org on g.d.o)
Mentor: Karoly Negyesi (chx)
Co-mentor(s): David Strauss (davidstrauss)
Local mentor(s):
Current status: Finished manual conflict resolution in a sandbox, working logic into module.
Description
This project focuses on handling node conflicts. Currently when a user tries to save a node that has been edited (and saved) before they have submitted, an error appears and the edit is blocked. This module aims to resolve these issues automatically if possible. If not, it will provide tools and an interface to interactively merge the two different versions of the node.
Project schedule
-
April 20th:
Determine acceptance and begin work on the project.
-
April 20th - May 23rd:
- Determine module workflow (generate diagrams concerning program flow and user interface)
Setup project on d.o and community feedback area on g.d.o.Develop module that will allow the editing of revisions that are older than the active revision, without losing any data and storing the update pathsSee the Revision-Fu Project on D.O- Discuss with mentors and community optimal project direction and tune roadmap to the tasks required
- Determine time and format mentors would like updates and code reviews / commits
-
May 23rd - July 6th:
Research various diff processes (native to host, PHP, other tools).- Code basic settings area (this will be extended throughout development).
Code diff logic- The actual diff / patch portion is handled by a worker module (which just works :))
Code patch generation and test applying the patch to the “working node”- Again this is handled by the worker module, which returns the merged result and any conflicts
Code auto resolution using both diff and patch code previously mentioned- This has been done, but not with diff and patch code, but rather handed off to a worker module who returns the result of the merge and any conflicts. If no conflicts occur then the content is automatically merged (while keeping revisions along the way for housekeeping purposes). Should a conflict occur the merged result is not stored and the entry is displayed on the conflicts page.
At this point should the automatic resolution fail we will still supply error that the node content cannot be changed.
*This is complete except that when there is a failure of automatic resolution the node simply appears on an admin page noting conflict. Which is what the module should be doing as conflicts can be handled versus simply telling the content creator "NO! You cannot create that"
-
July 6th - August 10th:
- Code Manual conflict resolution
- Involves displaying the diff to the user in a friendly way
- Let the user interact with the two versions and store the result
- Develop out the worker modules so that the administrator can choose one of three solutions.
- Develop D7 Port
- Code Manual conflict resolution