Allow overlapping (and disjoint) dive trips

We used to have the rule that a dive trip has to have all dives in it in
sequential order, even though our XML file really is much more flexible,
and allows arbitrary nesting of dives within a dive trip.

Put another way, the old model had fairly inflexible rules:

 - the dive array is sorted by time

 - a dive trip is always a contiguous slice of this sorted array

which makes perfect sense when you think of the dive and trip list as a
physical activity by one person, but leads to various very subtle issues
in the general case when there are no guarantees that the user then uses
subsurface that way.

In particular, if you load the XML files of two divers that have
overlapping dive trips, the end result is incredibly messy, and does not
conform to the above model at all.

There's two ways to enforce such conformance:

 - disallow that kind of behavior entirely.

   This is actually hard.  Our XML files aren't date-based, they are
   based on XML nesting rules, and even a single XML file can have
   nesting that violates the date ordering.  With multiple XML files,
   it's trivial to do in practice, and while we could just fail at
   loading, the failure would have to be a hard failure that leaves the
   user no way to use the data at all.

 - try to "fix it up" by sorting, splitting, and combining dive trips
   automatically.

   Dirk had a patch to do this, but it really does destroy the actual
   dive data: if you load both mine and Dirk's dive trips, you ended up
   with a result that followed the above two technical rules, but that
   didn't actually make any *sense*.

So this patch doesn't try to enforce the rules, and instead just changes
them to be more generic:

 - the dive array is still sorted by dive time

 - a dive trip is just an arbitrary collection of dives.

The relaxed rules means that mixing dives and dive trips for two people
is trivial, and we can easily handle any XML file.  The dive trip is
defined by the XML nesting level, and is totally independent of any
date-based sorting.

It does require a few things:

 - when we save our dive data, we have to do it hierarchically by dive
   trip, not just by walking the dive array linearly.

 - similarly, when we create the dive tree model, we can't just blindly
   walk the array of dives one by one, we have to look up the correct
   trip (parent)

 - when we try to merge two dives that are adjacent (by date sorting),
   we can't do it if they are in different trips.

but apart from that, nothing else really changes.

NOTE! Despite the new relaxed model, creating totally disjoing dive
trips is not all that easy (nor is there any *reason* for it to be
easty).  Our GUI interfaces still are "add dive to trip above" etc, and
the automatic adding of dives to dive trips is obviously still based on
date.

So this does not really change the expected normal usage, the relaxed
data structure rules just mean that we don't need to worry about the odd
cases as much, because we can just let them be.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>

1 files changed, 4 insertions, 0 deletions

diff --git a/dive.c b/dive.c
index 081c7eb25..98b96b3ff 100644
--- a/dive.c
+++ b/dive.c
@@ -1209,6 +1209,10 @@ static int likely_same_dive(struct dive *a, struct dive *b)
 {
 	int fuzz, match;
 
+	/* Don't try to merge dives in different trips */
+	if (a->divetrip && b->divetrip && a->divetrip != b->divetrip)
+		return 0;
+
 	/*
 	 * Do some basic sanity testing of the values we
 	 * have filled in during 'fixup_dive()'