Comments on latest changes

Linus Torvalds torvalds at linux-foundation.org
Mon Aug 20 10:29:54 PDT 2012


On Mon, Aug 20, 2012 at 10:04 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> The constraint that I would enforce is that dive trips need to be
> sequential, i.e. you can't have a dive in the middle of a trip not be
> part of a trip.

Well, you also have to have various other consistency issues, like
nesting. IOW, they presumably would have to nest perfectly, because we
can't *show* them in the tree structure if they don't.

And possibly limit it to a single layer of nesting (at which point
"nest perfectly" just means "no overlap").

Which in turn really means that it should probably be shown in the xml
as a true nesting level, and dives need to be inside the group that
they belong to.

And once you do that, you might decide that you actually *do* allow
overlap and/or dives that are outside of a trip despite the date
(because the nesting structure is not about the date, but about the
structure of the xml). So then the dive date part becomes irrelevant
as a global sorting thing, and only relevant to sort within the trip.

So then you can throw all the constraints away, which would simplify
some things, at the cost of having the explicit nesting (and the
explicit nesting does have some cost: it means that you need to have
ways to move dives between trips etc). Throwing constraints away is
good, because right now we allow importing data from multiple xml
files (or other, non-xml sources), and that would work fine with
explicit nesting in the files themselves, but it leads to trouble if
we have some date-based separate trip-list (what do you do when trips
collide because you tracked them differently in two files?)

Btw, if you do track the trips explicitly (whether as a nesting thing
or as a "fake dive"), the separate question about "what about
selection" goes away, because we'd have a structure to remember
whether a trip is selected or not. So it does solve that problem.

One of the reasons I'm not a huge fan of explicit trips is that it
will result in us having to have various new edit dialogs etc for the
trip data. Stuff we can ignore as long as it's just an implicit
grouping.

But I'm ok with it conceptually (whether implemented as an explicit
nesting thing or as a magic dive thing). I just suspect it's a
potential source of *lots* of new issues.

Doing them as "fake dives" and just using the fake dives as separators
- not ranges - might be easier. IOW, we could have a zero-length dive
mean "dive trip starts".

                  Linus


More information about the subsurface mailing list