search

MerginMaps / docs

Documentation repository for merginmaps.com/docs
https://merginmaps.com/docs
Creative Commons Attribution 4.0 International
12 stars 15 forks source link

A section on "how to avoid conflict files" #106

Closed saberraz closed 2 years ago

saberraz commented 2 years ago

It will be good to make it clear to the users what conflict files are and how to avoid them.

1- Always use GeoPackages for survey 2- Add some extra field attributes to the survey layer with different types (e.g. a couple of texts, int, real, date/time, etc) and hide them in the form design. If you need extra fields later in the survey, just alias those fields and add them to form. 3- If you do not want a field, just remove it from form 4- Instead of renaming a field, change the alias 5- Do not add a new table to your survey layer. Create a new GeoPackage with that table and add it as a separate GeoPackage

PeterPetrik commented 2 years ago

closely related to #19

saberraz commented 2 years ago

Also, if you have to change database schema, follow the correct procedure: 1-All devices sync before you change the schema 2- The project gets removed after sync from the devices 3- Change of schema in QGIS and sync 4- Fresh download of the projects on the devices

saberraz commented 2 years ago

And, a section on how to resolve the conflict files: manually :)

PeterPetrik commented 2 years ago

Do you have smoe recommended steps/trics for manual resolving?

saberraz commented 2 years ago

I look into two options: 1- Manual: just asking the user the whereabouts of were their work took place and identify those features visually. Then copy and paste those features to the survey table making sure the values have been transferred over correctly.

2- Semi-automatic: change the schema of the table in the conflict file to match the new schema and run "Detect dataset changes" algorithm from the processing tool. You then need to go though the result and ensure the changes detected are the ones you expect for both attribute values and geometry.

wonder-sk commented 2 years ago

below is my unfinished draft for a page about conflicts

Sometimes Mergin users may see conflict files appearing in their projects. This page explains when conflicts can happen, how to deal with them and how to prevent them.

Conflicts can happen when two users edit some files in a shared project at once. The technology behind Mergin service makes effort to merge changes from individual users automatically and therefore conflict do not happen normally, even if multiple people edit a single data source (e.g. a GeoPackage). However there are still some occasions when Mergin is unable to automatically resolve conflicts and it will create conflict files in projects.

There are two types of conflicts:

  1. edit conflicts
  2. conflicted copies

Edit conflicts

Let's think of a survey of benches in a park conducted by Jack and Jill. They start with a vector layer of points with benches and they need to asses condition of the benches by filling in a couple of attributes. They split the work into two halves and do the survey. By a mistake, Jack also surveys a bench assigned to Jill - they both end up editing attributes of the same point, with slightly different values. How will Mergin handle that?

TODO: illustration of edits - diamond shape - base, Jack, Jill, result

If Jack is the first one to sync his changes, and then Jill syncs her changes, at the time of Jill's sync, Mergin knows they have a conflict in edits for that one bench. The editor who syncs last "wins", so in this case Jill's changes to that bench would be kept and Jack's changes would be overwritten (but of course all his non-conflicting edits to other benches would be kept). In case project admin would want to investigate the edit conflict, Mergin keeps a record about it - if the survey is stored e.g. in data.gpkg, then a JSON file named data (edit conflict, jack v123).json would be created, containing list of conflicts. For each conflicting attribute value, the file lists the original value and the two different modified versions.

TODO: input wasn't creating edit conflicts at all - fixed in 1.3 release - https://github.com/lutraconsulting/input/issues/1738

TODO: plugin not doing this naming yet - https://github.com/lutraconsulting/mergin-py-client/issues/62

Conflicted copy

TODO: example when that happens (change of database schema)

TODO