Strange duplication of dives

[Linus Torvalds]

On Sun, Dec 16, 2012 at 9:53 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> Oh, so this can only happen the very first time he downloads dives - all
> existing dives lack diveid and the new ones then are matched as you
> describe? Or can this also happen if the xml file already contains some
> dives with a diveid and some without?

Well, it only happens "the first time" you download the info, and you
have old information without it.

The next download, you will now have the "duplicate" dives that *do*
have the new dive computer information, so you shouldn't get even more
duplicates.

But if you remove the duplicates, they'll go away and you'll be back
to square one again.

Anyway, if we relax the "one minute apart" rule, they'll all merge,
and once they merge, it should be ok - we'll take the dive computer
information during the merge, and not see the problem again.

Except you need the patch I just sent for that to really work.

AND you need the patch to relax the merging, which I haven't sent out.
Except I described just changing "likely_same_dive()" to just always
make the cut-off be 5 minutes regardless of dive computer matching..
That's a hack, I'll think about a better model.

> And anyway, in the case of "no dive has a diveid" (which is what all
> regular users upgrading from 2.1 to 3.0 will encounter), shouldn't we
> fall back to the old date based cutoff?

We do. But the sensus pro dive dates are crap. So it has never worked.
I suspect that David *used* to have his computer date "close enough",
and the downloaded dives got dates that were within a minute of each
other, but that his newer downloads have crept far enough away from
each other - either due to horribly bad clock in the sensus, or
because he doesn't run ntp on his computer (or didn't use to - maybe
his computer clock *now* is good, but during the old downloads it
wasn't, or vice versa).

               Linus