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?
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
For non qobjects we could use qgadget for simple types
It may reduce code maintain, new type and data could be merged automatically
If using the meta system
The hard bit is how do we merge slightly modified lists
I haven't figured that out yet
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
I haven't really analyzed it but I'm assuming shots with the same exact measurements are pretty rare...of course shots with the same from/to station will be even rarer except in the case of resurvey...
but yeah what I'm describing wouldn't work well in the case of multiple changes by different people in different places...it would only work for updating cavewhere data
I'm sure git works well for managing changes to survex, compass, and walls data files, if we eventually had metacave it might work well for that too
It would be hard to detect the instance where people have enter duplicate data with uuid method.