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

[Jef Driesen]

On 2014-07-22 02:36, Linus Torvalds wrote:
> 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.

Libdivecomputer should always return the dives in newest to oldest 
order, no matter how the underlying protocol works. This is an 
requirement for an efficient implementation of the "download only new 
dives" feature. So if you noticed that dives are returned in some other 
order, then please report as a bug.

> 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 think it's a bad idea to treat non-trip dives different. Not everyone 
organizes dives in trips. For example when diving locally, grouping 
dives in trips doesn't make much sense. But disabling the automatic 
merging is still a very useful feature in such case.

Jef