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:

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

< Previous Next >
Follow Ups