Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detect conflicts when collaborating on files locally before github sync #9

Open
JensLincke opened this issue Apr 27, 2016 · 4 comments

Comments

@JensLincke
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link

j4yk commented Apr 27, 2016 via email

@jgraichen
Copy link
Member

jgraichen commented Jul 7, 2016

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants