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

dixon_ created an issue. See original summary.

dixon_’s picture

Title: Co-maintaining a Drupal 8 version » Co-maintaining Conflict module for Drupal 8
drumm’s picture

This 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:

It's advised that you install this module right after installing your site (or before adding content). Switching storage handler involves a migration of existing content which needs work.

Could Conflict still act without the Multiversion dependency; or a “simple” Multiversion configuration that keeps the revision graph from forking?

dixon_’s picture

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

dixon_’s picture

Issue summary: View changes
drumm’s picture

Assigned: Unassigned » drumm
Status: Needs review » Fixed

Great, granted!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.