Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jl
    @jlillest
    I make chat good
    Andy Edwards
    @jedwards1211
    Man should I start using this instead of e-mail and sporadic GitHub comments for discussions?
    vpicaver
    @vpicaver
    Yea, sounds good
    Andy Edwards
    @jedwards1211
    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?
    vpicaver
    @vpicaver
    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
    vpicaver
    @vpicaver
    We also need to figure out how handle merge conflicts
    vpicaver
    @vpicaver
    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
    vpicaver
    @vpicaver
    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
    @jedwards1211
    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