Mailinglist Archive: opensuse-packaging (155 mails)

< Previous Next >
Re: [opensuse-packaging] Re: Proper version scheme for packages from git, hg, svn, ...
  • From: Adam Spiers <aspiers@xxxxxxxx>
  • Date: Thu, 23 Jan 2014 11:49:55 +0000
  • Message-id: <20140123114955.GA29223@pacific.linksys.moosehall>
Matwey V. Kornilov (matwey.kornilov@xxxxxxxxx) 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:

/ /

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups