Open JensLincke opened 8 years ago
foo.js
foo.js
foo.js
This is a typical conflicting scenario that we have to solve.
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...
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).
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.
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.