On Friday, 17 April 2009 13:12:56 Adrian Schröter wrote:
And your "really, really" indicates that you
still not accept that our main
goal is to show up changes and conflicts as soon as possible. But this is
the approach of the OBS. We trigger builds automatically when something
below changes, so we need also show conflicting source changes immediatly
to all parties.
I'm really sorry, but the nonsense you keep reiterating leaves me no choice
but to assume that you didn't understand any of what I've been trying to
explain to you in this thread -- very carefully, and twice already. Let me
start over again; maybe we can make some more progress this time.
(1) Let's assume that we have a diff(x, y) operation which computes the
difference between packages x and y, and an apply(d, z) operation which
applies the difference d between two packages to another package z. We
know that apply(diff(x, y), x) = y is always true.
(2) Let's assume that we also have a merge(z, x, y) operation which merges
two packages z and y, which have a common ancestor x. We also have a
fourth operation merge'(z, x, y) which is implemented as
apply(diff(x, y), z).
Because merge gets all three packages as input, it produces better
results than merge'.
With these tools in hand, we can describe what the basic idea of source links
is, what happens currently when a package gets checked out and built, and
when a new revision is created.
Once that is understood we can argue what may be improved. But let's first
describe what we are trying to do and what we are actually doing today.
Imagine that we have four packages, A, A', A'', and B. Let's assume
and B are modified versions of A, and that A'' is a modified version of A'.
A, A', A'', and B are all full packages, and neither is a diff of anything.
Let's go back in time to here, assuming that the packages are created in the
order A, B, A', A'':
What we want to achieve is this: when A is changed, we want those changes to
propagate to B, even when B itself has not been changed. At this point in
We want to build merge(B, A, A'). *This* is what source links really are
Instead, what the build service implements is this:
* Instead of storing B, it stores dAB = diff(A, B). That's all fine, and
storing the diff may actually be more efficient. Remember that we can
recreate B = apply(dAB, A). But wait ... the build service does not
remember that it generated dAB from A:
* Due to the redundancy in dAB, apply(dAB, A') still succeeds (the link still
works), and everyone is happy. Next, the maintainer of A* creates A'':
* This time, apply(dAB, A'') no longer works (a "broken link"). The
service forgot that dAB was created from A, but it can can extract from
its logs that apply(dAB, A) and apply(DAB, A') both succeeded. In the
desperate attempt to repair the link, it figures out the last version of
A* that dAB did still apply against,
and it does a merge(A'', A', apply(dAB, A')).
If we are lucky, the result will be the same as merge(A'', A, B), but that
is only if we are really lucky.
The fix, as I have already pointed out, is very easy: don't forget what
diffs were generated from:
Then, it is trivial to see that A'' and B have A as their common ancestor,
and merging suddenly becomes easy:
B = apply(dAB, A)
merge(B, A, A'')
Thanks for listening this time!
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org