My suggestion, use the couchDB system which prevents overwriting of competing changes. It is a simplified when it comes to git, which stores the entire change history.
id is optional as it only helps to ensure that the update targets the correct initial package.
rev: is a new rev_id
old_rev: is the rev_id of the package that is updated
If I send an update: I have to send the rev_uuid of the previous package. If somebody else changed the content and the package has a new rev_id, then I first have to pull that change, merge, and then can push my change with the now known rev_uuid.
How do we want to track, if content changed after the .eln import?
How do we want to handle updates to the .eln?
My suggestion, use the couchDB system which prevents overwriting of competing changes. It is a simplified when it comes to git, which stores the entire change history.
It requires 3 additional key-values id: uuid_v4 rev: uuid_v4 old_rev: uuid_v4
If I send an update: I have to send the rev_uuid of the previous package. If somebody else changed the content and the package has a new rev_id, then I first have to pull that change, merge, and then can push my change with the now known rev_uuid.
How do we want to track, if content changed after the .eln import?