23 Jan
2014
23 Jan
'14

12:49

Matwey V. Kornilov (matwey.kornilov(a)gmail.com) wrote:

14.01.2014 17:21, Adam Spiers пишет:

Thank you, that helps illustrate my point.
Distance(A,C) <= Distance(A,B) + Distance(B,C)
implies the possibility of a "shortcut" from A to C. And in this
context, that's precisely what we are trying to avoid. Consider this
commit graph, with time going from left to right:
.-A--B--C--M
/ /
I----------D
I is the base commit, M is a merge commit, and there is a shortcut
from I to M if you go via D instead of A/B/C:
Distance(I,C) == 3
Distance(C,M) == 1
Distance(I,M) == 2
We are looking for a metric which does *not* have the possibility of
shortcuts, because we need our metric to be strictly monotonic
increasing, as mentioned many times earlier in this thread. It's
actually a one-dimensional metric, whereas most people immediately
think of a two- or three-dimensional metric when considering distance.
It's also a directional metric, being measured always from a tag at
some revision in the past, to the current revision - and never the
other way around. So the axiom
Distance(A,B) == Distance(B,A),
doesn't apply here either.
Hmm... I think "distance" implies a
continuous amount (i.e. float)
rather than a discrete number (integer),

The distance implies that
Distance(A,B) == Distance(B,A),
Distance(A,A) = 0,
Distance(A,C) <= Distance(A,B) + Distance(B,C). No matter continuous or discrete.

When I said "a continuous amount (i.e. float) rather than a discrete
number (integer)", I meant "as well as", because integers are of
course a subset of irrational numbers. So we agree that the term
"distance" implies the possibility of a non-integer amount, which
again is something we need to avoid in this context.
A fourth reason for avoiding the term "distance" is that it's simply
too generic. My proposed alternative "revision offset" has obvious
connotations of representing a discrete number of hops from a given
point in the commit graph, whereas there are a number of ways in which
the distance between two commits could be defined (e.g. Levenshtein
distance). There's simply no good reason to accommodate such
ambiguity when we can avoid it.
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org