Matwey V. Kornilov (matwey.kornilov@gmail.com) wrote:
14.01.2014 17:21, Adam Spiers пишет:
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).
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.
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@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org