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 _______________________________________________ subsurface mailing list subsurface@hohndel.org http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface