[RFC PATCH] Add 'create new trip' option for downloading dives from the dive computer

[Martin Gysel]

Am 22.07.2014 02:36, schrieb Linus Torvalds:
> 
> So I've now had the occasional situation where I'm sharing dive computers 
> with others - we've had it with Dirk and me switching computers, and last 
> week I encountered it when wanting to look and compare dives with my 
> daughter who used one of my computers during her dives.
> 
> I've also had it happen "indirectly" when just serviving my dive computer, 
> and as a result the dive computer gets reset with test dives that may have 
> odd times and dates, and generally being uninteresting.
> 
> That generally isn't a huge problem, *except* for the fact that when you 
> download the dives, the auto-merging of dives ends up meaning that these 
> dives can incorrectly pollute your own dive log. You might want to look at 
> your and your daughters dives side by side in the same app, and switch 
> between the two, for example - *without* merging the two into one dive.
> 
> And when having odd extraneous dives after servicing, since the date and 
> time isn't ncessarily correctly set (think battery change etc), the extra 
> dives may show up in random places in your history, and not be all that 
> easy to see.
> 
> In other words, it can get messy.
> 
> Last time this happened, I mentioned to Dirk that maybe we should have a 
> "download only last N days" in the dive computer download logic, but that 
> ends up having its own set of problems, like the fact that some dive 
> computers will only download things in a certain order (and not 
> necessarily latest first), so it's hard to say "start at xyz". It also 
> ends up being a messy interface.
> 
> This patch is small and simple, and takes a completely different approach: 
> it adds a check box for creating a new dive trip that all the newly 
> downloaded dives get put into.  That not only happens to be very easy for 
> us to do, but it ends up being quite flexible, in that it basically 
> "quarantines" the newly downloaded dives into a trip of their own.
> 
> That private trip means that:
> 
>  - the newly downloaded dives will not be merged with your old dives if 
>    they are already in a trip.
> 
>  - the newly downloaded dives are easy to find even if they have odd 
>    dates, because they are not spread out chronologically intermixed with 
>    other dives, since we sort by trip first and dive date second.
> 
>  - you can now edit/delete the dives as you wish, and then you have the 
>    choice to perhaps merge the trips/dives manually for those dives you 
>    wish to merge.
> 
> In other words, it solves the mess problem. 
> 
> One caveat: it *only* solves the mess problem if you keep all your other 
> dives in trips too. If you have old dives that aren't in some trip, and 
> they overlap with the newly downloaded dives, the dive merging might still 
> choose to merge that old non-trip dive with the newly downloaded dive that 
> has the new private trip. But at least for my use case, this isn't really 
> a problem.

I like the idea but why not disable the merging unconditionally in that
case. I think it's not really intuitive the have an option to create a
new trip but still allow merging with older dives. another option would
be to have a second checkbox '(dis?)allow merging with existing dives
not associated with a trip' but that seems quite complicate from a user
point of view

another option or way to do it would be the create a staging area which
basically is a special trip which is visible if dives are in it
otherwise not. from this area the user can edit, move, merge with others
or delete the dives.

/martin