Wiki UI doesn't prevent concurrent editing

If two users are editing the same wiki page at the same time and both hit save then one user's changes will overwrite the other's changes. No data is lost because the wiki is just a git repo, but it does mean that who ever clicks save last "wins" and the other user's changes are stuck back in the page history.

Instead of this behavior it should notify the user who saves last that the page has changed since editing began and give them a chance to merge their version of the page with the new version. Because the wiki is just a git repository the change in version is really easy to detect. A nice UI for merging the disparate versions of the pages is probably more work, but it can't be too difficult given all of the other nice UI features in GitLab for diffing code.

This occurs on version 7.11.2.

I'm also seeing this in the hosted gitlab.com version. I view this as a serious issue that needs to be addressed ASAP. There's also no way to revert, or to go back to the earlier versions and start editing those. There's no easy way to merge changes either. After using Confluence it's really hard to use this wiki.

Would it be possible to put the second change in a new branch when a concurrent access is detected, so the editor can later merge its modifications, first manually then maybe later with the possibility to merge it automatically?

Added ~131895 label

mentioned in issue #4215 (closed)

This issue affects our group also and is a blocker for reasonable usage of the wiki feature of gitlab.
It should be relatively easy to detect whether a wiki page was edited in between beginning and saving of editing (store the timestamp when editing was started locally in the browser, then check for a commit newer than the timestamp when the page is saved).
But how should this event be handled in UI?
I would try to do a MR but don't think I will come further than just showing a notice like "Sorry, a newer version of this page exists. Please refresh and edit again".
@rymai Would this have a chance to be accepted/merged?

@rymai As you are "merge request coach": Any opinion on my question/proposal?
I do not want to invest time into this if the proposed implementation is too simple and doesn't have a chance to get merged.

@nightvisi0n I think your proposal makes sense, we could probably store the timestamp in Redis (using Rails.cache), and ask to refresh the page, as a first iteration. Then in further iteration we could imagine using UI conflict resolution.

@DouweM Does it make sense to you?

Note: We cannot use optimistic locking since wiki pages are not DB records, they're Git objects.

Instead of storing the timestamp why not store the git object id for the blob that corresponds to the file?

You could get the same effect as an optimistic DB lock by only committing the change on the server if the blob's current id corresponds with the one transmitted by the UI. If they don't match then you'd know that there needs to be a merge.

@rymai @nightvisi0n @jgibson We don't need to store anything extra, since we can already ask Git when the file was last changed. We can do something very similar to https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5122, which adds this for web edits to the main Git repo, by adding a hidden last_commit_sha field to the form.

added ~123454 label

removed ~131895 label

Indeed, thanks @DouweM!

added ~480950 label

This still exists in 8.17.0 CE (77254ab7). Any timeframe for the fix?

mentioned in merge request !9707 (merged)

I'm working on this !9707 (merged).

Thanks @hiroponz!

assigned to @hiroponz

mentioned in issue #29511 (closed)

closed via merge request !9707 (merged)

mentioned in commit 64131f04

mentioned in merge request !14785