Need SOP for avoiding ID clashes when 1 editor has multiple branches awaiting merge

[dosumis]

Branches that are expected to be long require their own ID range. But what should we do in the case of branches with new terms that stick around for a couple of days awaiting review? In these cases, starting a new branch and adding new terms will => ID clashes. Easiest way to avoid this is to check the highest new ID in the old branch and set ID counter to start from this ID + 1.

[ukemi]

If you are using your ID range, doesn't asking Protege to remember identifiers between sessions circumvent this?

[krchristie]

I also thought Protege remembers this. I encountered something that looked odd a few weeks ago and ended up remaking a term several terms without committing any except the last time. Protege gave it a new & different ID every time even though the earlier terms were never committed.

[dosumis]

I had an ID clash from twin branches quite recently. But now I see that I don't have the 'remember ID between sessions' option clicked. Wonder if this works when switching ID setup (something I also do quite a bit, e.g. if editing CL or RO)?

[cmungall]

Either way we probably need better checks in place to detect collisions before merging into master; in theory the obo format checks should stop this (e.g. >1 label for an ID) but better to be robust with a sparql.

…

On 5 Jul 2017, at 9:27, David Osumi-Sutherland wrote: Branches that are expected to be long require their own ID range. But what should we do in the case of branches with new terms that stick around for a couple of days awaiting review? In these cases, starting a new branch and adding new terms will => ID clashes. Easiest way to avoid this is to check the highest new ID in the old branch and set ID counter to start from this ID + 1. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #13812

[ukemi]

And if we have a collision, what do we do, hand-edit the file. It seems better if we try very hard to catch this upstream. If I recall correctly, it remembers even when you switch ID setup, but I think I tried that ages ago on a much earlier version. You should try testing that again.

[pgaudet]

@balhoff Can a check be added for this ?

[balhoff]

I have a proposal for managing this in ontodev/robot#763

[dosumis]

I'm pretty sure that the 'remember ID' option is sufficient to avoid clashes of this type - as long as you do all your edits on one machine.

[pgaudet]

I dont think this is a problem anymore