Mailinglist Archive: opensuse-packaging (100 mails)

< Previous Next >
Re: [opensuse-packaging] Source links semantics, broken links, and merging
  • From: Michael Matz <matz@xxxxxxx>
  • Date: Sat, 18 Apr 2009 14:08:35 +0200 (CEST)
  • Message-id: <Pine.LNX.4.64.0904181345330.29566@xxxxxxxxxxxxx>

On Sat, 18 Apr 2009, Andreas Gruenbacher wrote:

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.

I think the core of the misunderstanding of Adrian is the following: he
wants that the builders always build the newest versions of all packages,
and if it's a link he wants to build against the newest version
of the target package applying the diff of that link against that version.
He wants this for many reasons, one of them being that brokeness ("the
diff doesn't apply anymore") is detected early.

This is all fine and good, I think most people agree.

Now the misunderstanding is that he thinks this is in any way affected by
Andreas' proposal. Let's state one thing very clearly: It Is Not!
Remembering the common ancestor doesn't affect how the builders check out
packages or anything. Everything that works now works exactly the same as
before. The source links would contain an addition field that contains
the target rev when the link was created (or the diff). The builder can
ignore this field if it so chooses.

The confusion arises of the mixture of two things:
(a) "checkout" of the packages by the builders (to build the stuff)
(b) "checkout" of the packages by the developers (to work on the stuff)

These two are related but different.

Adrian talks about (a), but Andreas is mostly concerned about (b). He
wants to make very sure that working with the packages is easy and
reliable. In particular, once the builders have found out that a diff
doesn't apply anymore, how the developer is supposed to fix this breakage
in the most easy way. A reliable three-way merge is the best option here.
And for this remembering the common base version is absolutely required,
there's no way around that.

Btw. I wholeheartedly agree with everything he says, currently the source
link concept is broken in a very peculiar way. One which isn't very
obvious but not hard to fix (namely by remembering the common base
revision). The breakage isn't obvious to someone not used to three-way
merges because it leads to errors only sometimes. The pseudo-merge
without the missing information often magically works (or seems to work
when it really doesn't). But if it doesn't work then this missing info
will lead to unfixable breakage.

Hence, let's please do as Andreas proposes. It's really required. Not
optionally. The base revision (common ancestor) has to be stored in
_every_ source link, not just when the creator requested so.

< Previous Next >