detect conflicts when collaborating on files locally before github sync

[JensLincke]

idea: commit on every put and squash commits later as needed (either while syncing or when merging a feature branch).

Another option would be to keep a local edit history beside git... which would be easy to build but make everything just more complex.

[JensLincke]

User Case:

1. Jens loads a file foo.js
2. Jens makes change A
3. Fabio loads, makes change B,
4. Jens saves foo.js
5. Fabio saves foo.js

This is a typical conflicting scenario that we have to solve.

• Currently we loose either change A or change B completely.
• We want to detect that there is / was a conflict
• We want to keep both changes in the history
• We would like the system to help us resolve the conflict by potentially combining change A or change B

[j4yk]

Another possibility to solve this would be concurrent immediate editing like in Google Docs or Etherpad. But the feasibility is certainly limited by our human resources and time...

[jgraichen]

We're exploring the possibility of providing a conflict detection within the file systems. This will most likely employ the Entity Tag [1] and will require the userland (editor) to track this and handle conflicts.

I'll give a quick overview:

When reading a file a ETag Header, such as ETag: e645afe6745 will be returned. The editor has to store this ETag while the file is in editing mode. When trying to save the file the editor will add a header to the PUT request: If-Match: e645afe6745. The backend will use the ETag to determine if the file has not changed (e.g. on GitHub). This can probably by done by using the same mechanism (ETag) when talking to GitHub or Dropbox. If no change is detected a regular 2xx response will be returned, but if the ETag does not match - the file was modified - a 412 Precondition Failed will be returned. The userland client (e.g. editor) can fetch the file again and present a diffing tool to the user, automatically merge and save again, or just show an error.

Please note that this is not yet implemented in the filesystems. We're also still exploring how to use the filesystems in lively4-server directly and how to do caching and conflict detection on the http filesystem, that is only passing requests to the server (e.g. on lively-kernel.org).

[1] https://en.wikipedia.org/wiki/HTTP_ETag

[jgraichen]

Concurrently editing like on Google Docs would require a complete own service infrastructure and new editors. It certainly will work with privately mounted storage such as dropboxes etc.