# 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:

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.

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

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 > |