As part of porting Deploy to Drupal 8 (#2608242: [deploy] Deploy module) we're a team of people who are working on a suite of dependencies consisting mainly of Multiversion. With Multiversion entity revisions are no longer linear, they can be trees (or rather a directed acyclic graph). And we're looking to add the ability to handle conflicts and merge strategies for revisions.
I think it would make sense to use this module namespace, hence me asking to become co-maintainer for the Drupal 8 version of this module.
The high level overview of the plans for our take on the Conflict module for Drupal 8 would be:
- Optional dependency on Multiversion (to support revisions as a graph where revisions may conflict with each other, i.e. have the same parent revision)
- Provide a plugin system consisting of two types of plugins: Unattended and Attended merge strategies
- On entity save an unattended merge will always be attempted
- On failed unattended merge the user will be notified and can solve the conflict with an attended merge in the UI
- Default plugins we are considering to implement:
- Unattended: Recursive 3-way merge (to handle cases where a criss cross merge have happened)
- Attended: Pick a winner
- Attended: Manual merge (using something like Code Mirror for the merge UI)
- Stand-alone Composer libraries for handling the actual merge and finding lowest common ancestors in the graph
If your future plans for Conflict module and Drupal 8 doesn't align with the rough plans I've outlined above, then I would just go ahead and create another d.o project for this instead, but thought it would be worth asking for this namespace first :)
Comments
Comment #2
dixon_Comment #3
drummThis looks like an expansion of the scope of this module. D7 Conflict only considers the current edits and the current revision.
I could see Multiversion being useful on Drupal.org documentation pages, but not issues. Issues benefit from having a clear canonical revision. And from the Multiversion project page:
Could Conflict still act without the Multiversion dependency; or a “simple” Multiversion configuration that keeps the revision graph from forking?
Comment #4
dixon_The work we're looking to do for this has (since I posted this issue) become an official core initiative. See #2721129: Workflow Initiative. So it would be really great to be able to use this namespace for an experimental module that eventually will be included in core :)
@drumm Yes I believe we can and should do this without a dependency on Multiversion (or the "archive/purge storage" as called in the core initiative). This was even discussed during a meeting with core maintainers we has last week. See notes here: #2721129-42: Workflow Initiative
Comment #5
dixon_Comment #6
drummGreat, granted!