Man should I start using this instead of e-mail and sporadic GitHub comments for discussions?
Yea, sounds good
so I was thinking about how to do data merging
I think in general we can just look for shots with the same exact combo of from/to/dist/azm/inc
if two trips have just one match like that, we assume they're the same
otherwise we let the user decide
and when we "merge" one trip into another, we can actually just replace it with the entire new trip data, so that deleted shots will stay deleted after the "merge"
also for trips that are new, we can see if they're siblings of matched trips in the tree and if so, mark them to add to the matched trips' cave by default
do you see any problems with that approach?
So have thought about this a lot in the pass
I really want to have something where multiple people could work on the file and merge it together
It might be interesting to have a mergetool if using version control.
One idea I had was using uuid for for each object. This won't work very for merging from walls, compass, survex
We also need to figure out how handle merge conflicts
We might be able to use qt's meta system to help use do the iteration for merge comparison.
For non qobjects we could use qgadget for simple types
It may reduce code maintain, new type and data could be merged automatically
We may need to have an ignore property list for each type if we don't want to compare the properties
If using the meta system
The hard bit is how do we merge slightly modified lists
I haven't figured that out yet
Huh. Yeah, I can see how that would make sense for multiple people editing data in cavewhere directly
one question about using uuids -- what happens if two people independently add the same shots?
my focus was different, if people are using walls for instance it will probably remain their primary data source, and there just needs to be a smooth process to import updated walls data into cavewhere
the thing that makes that tricky is people could change cave, trip, and station names
or also station prefixes, which might change a whole slew of station names at once
but for instance, if someone corrects a measurement or two in a trip -- most of the other shots remain the same, and if just one matches the station names and measurements of a shot already in Cavewhere, there's a pretty good chance it's the same trip, even if the trip was renamed
optionally I could use a levenshtein distance tree to look for the most similar trip names in case typos are corrected, but for complete renames matching measurements is probably the best bet