Concurrent editing

[cassandraoid]

- Do you want to request a feature or report a bug?

Feature

- What is the current behavior?

Right now I have to verbalize if I am making changes on something that another person may be making changes on... this is very confusing and I could see it leading to problems.

- What is the expected behavior?

Not sure what the best fix would be.. a notification of currently be edited by NAME would be helpful to know who to go to. Or when you go to SAVE it tells you that's not the most updated version? But then that could cause issues with edits I may have made and then would potentially loose.. I'd be wary against any roadblocks because if someone is editing (but not actively) then that would cause a bottleneck.

[Benaiah]

WordPress handles this by only allowing one active editor at a time, and showing a popup when you try to edit something that someone else is editing that lets you either cancel or take over editing (preventing inactive users from bottlenecking the entry entirely). That seems like a solid approach to me. I think true real-time communication is probably out - since we don't run a centralized server for netlify-cms, this would likely involve WebRTC, since it's the only way to do P2P in a browser :confused:. Instead, we could simply store this in some sort of metadata on the backend, though that sounds somewhat susceptible to race issues - for instance, A starts editing an entry, so their netlify-cms instance adds metadata to the backend, but B starts editing a quarter second later and the request to store that A is editing hasn't finished yet. Both then save, and we're in the same position we are now.

The other option I see is to build a nicer merge UI on top of Git and allow for simultaneous editing, but that's also a pretty large undertaking.

[rbq]

Maybe there is a way to (optionally) translate ongoing edits into (GitHub/Bitbucket/GitLab/Trello …) issues with the state of “doing” and a machine readable payload naming the file(s) being edited?

As far as I understand Netlify CMS, it tries to mimic humans editing repository contents using Git and a text editor. It would therefore make sense to me if the same principle would be applied to tracking who is currently doing what: Opening a resource would create an issue and related feature branch, saving would git commit, saving and closing the editor would git commit, git merge --squash and close the issue.

Disadvantages of this approach:

• The created (“Edit x.md”) issues would be virtually useless for humans.
• Cleaning up might be an issue.
  • Automatically discarding aborted issues might require “touching” the issue regularly to indicate that there is still an open editor session attached to it. The only ways to do that are probably (a) “Still working on this one …” comment spam or (b) autosaving (even empty) Git commits (to be squashed later).
  • When opening a “blocked” file, the editor could just name the existing issue with author name and relative time, asking if you want to discard it.

[tech4him1]

Isn't the backend idea that we have here similar to what we already have with the Editorial Workflow? Maybe we could use some of the ideas already implemented there to help build this.

[erquhart]

This is a biggie - for now we should improve the non-ff merge error messaging to help users understand that the likely cause is that the entry was already changed by someone else.

[erquhart]

There's also precedent for a sort of progressive enhancement, where a basic feature is added, but is limited to whatever a Git provider's API can do (as described by @rbq), and a more ideal alternate approach is also provided through an integration. The example of this is image handling, which can be done through the GitHub backend, but can be done much better through a custom integration that uses a separate non-Git asset store.

Likewise, we could provide an imperfect solution that does the trick using only the backend API, such as the locking technique @Benaiah mentioned, but then also put an integration for true realtime collaboration that leverages a separate API based service.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dmgawel]

Definitely needed and should not have stale status ;-)