Versioning vs graph persistence

[tmcw]

So, how do we resolve the question of loading new data into the graph versus having a consistent undo system? Does loaded data have a 'backdoor' where it exists in all graph versions? Does undo possibly wipe data that's downloaded from the map?

[jfirebaugh]

Well, somewhere there's a merge operation. Maybe Richard can give us an overview of how merging works in Potlatch?

In a functional approach, my starting point would be to model merge as a function (H, g) -> (H', C), with:

• H, a version history consisting of graphs {g0, g1, ... gn}
• g, the graph containing the new data
• H', a version history consisting of graphs {g0', g1', ... gn'}, where each gi' is the result of the maximal nonconflicting merge of gi with g. By "maximal nonconflicting", I mean merging everything that doesn't conflict and then returning the unmerged, conflicting portions in:
• C, a list of conflicts. Representation unknown.

[jfirebaugh]

Actually, the conflicts should be local to each graph version; if you undo an action that produced a conflict, you have one less conflict to resolve. Likewise, the act of resolving a conflict is an action that produces a new graph+conflict list. If you made the wrong resolution, you can undo it and choose a different resolution.

So make it (H, g) -> (H'), and the graph type itself includes a conflict list.

[systemed]

P2 doesn't really attempt to merge downloaded data with existing data. If a /map call returns a node or way that's already in P2's Connection storage, P2 simply skips that element. It's slightly suboptimal but I'm not aware of it causing problems in practice.

[jfirebaugh]

Interesting. I was assuming it worked like josm, which does do that. But if the P2 way works, let's do that as it's significantly simpler.

What does P2 do if a save operation fails due to a conflict?

[tmcw]

@jfirebaugh this is essentially implemented now, or no?

[jfirebaugh]

Yep.