Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
Repo info
    I make chat good
    Andy Edwards
    Man should I start using this instead of e-mail and sporadic GitHub comments for discussions?
    Yea, sounds good
    Andy Edwards
    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
    Andy Edwards
    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