[josm-dev] Jumbo Patch
Gabriel Ebner
ge at gabrielebner.at
Sat Dec 15 07:57:20 GMT 2007
On Sat, Dec 15, 2007 at 02:15:24AM +0100, Frederik Ramm wrote:
> 2. I have never fully understood the "Merge" code in JOSM, i.e. what
> happens when you load stuff from the server, of which some objects
> were present already, others not, and some were present and now come
> in a more recent version, while others were present and have been
> changed *and* come in a new version (i.e. conflict detection). We have
> to be reasonably sure that your code doesn't break these. Have you
> done any tests in that direction? Someone else recently spoke of
> improving the merge code, maybe he can help making sure this works.
The merge code is actually fairly simple (i.e. it does almost nothing fancy).
The catch is that there was originally quite much code duplication, misleading
names, out-of-date comments, and code edited by people who didn't really know
what they're doing (me).
Basically, we're just merging MergeVisitor.mergeds ("other") into
MergeVisitor.ds ("my"/"our") (and the visitor methods get called with prims
from mergeds).
Now, for every primitive from mergeds:
- we figure out whether we already have a primitive with the same id or
exactly the same contents (MergeVisitor.mergeAfterId)
- then we try to find a primitive from our dataset that is approximately
equal (MergeVisitor.match; it compares coordinates for nodes, nodes for
ways, members for relations)
- and if all fails, we just add it to our dataset.
All the while, we keep track of what primtives we have merged with what others
(MergeVisitor.merged; a hashtable from primitives in the other dataset to ones
in ours).
At the end, we're using this hashtable to modifiy the ways and relations in
our dataset to point to the correct primitives (i.e. those in our dataset;
MergeVisitor.fixReferences).
Gabriel.
More information about the josm-dev
mailing list