Mailinglist Archive: opensuse-buildservice (64 mails)

< Previous Next >
Re: [opensuse-buildservice] Revision history with wrong files
  • From: Hans-Peter Jansen <hpj@xxxxxxxxx>
  • Date: Fri, 27 Mar 2020 09:53:15 +0100
  • Message-id: <5532783.64QCPEPWqZ@xrated>
Dear Marcus,

I'm impressed and overwhelmed.

Am Mittwoch, 25. März 2020, 18:28:43 CET schrieb Marcus Hüwe:

[I've yanked the great description, Marcus, but IMHO, this should get a home
somewhere on the wiki. Thank you for these valuable insights into
discontinuous development processes]

Finally, we can discuss the potential options for the "expected" expanded
file set for X/B@r1, which could be displayed in the webui.

Let of_i denote the file set in P/A that is identified by revision i
(i = 3, 4, 5).
Let f_1 denote the file set in X/B that is identified by revision 1.
(f_1 = {foo, bar, baz, _link})

#
# Option a: expand against the latest/HEAD revision of the origin package
#

expand(f_1, of_5) = expand(f_1, NONE) = {foo, bar, xxx, yyy}

That's the status quo. Probably "unexpected" from a user's POV.

I would call this misleading. At least a note for the casual user would be in
order:

The branch of the <a href="link to pkg">origin package</a> couldn't be
expanded successfully for that revision. Expanding latest revision instead.

#
# Option b: expand against the file set of P/A that could have been seen
before # committing X/B@r2
#

expand(f_1, of_4) = {foo, bar}

Personally, that's what I would probably expect (assuming the usual commit
workflow: osc up; <change files>; osc ci (the "osc up" results in {foo,
bar})).

This is the behavior, that I've expected intuitively.

Potential issue: this does not work if X/B@r2 fixes a conflict (in this
case we could "go back" in the P/A timeline and "try" to expand against
the intermediate file sets until we "reach" the baserev).

This is an acceptable way to solve this dilemma IMHO, but depends on the costs
in terms of development and runtime resources of course.

Bud even without this, doing this manually is fine as well, since current
behavior is somewhat similar (probably even less problematic than status quo,
since the conflicting potential is (again intuitively) lower than merging with
HEAD.

#
# Option c: return the expanded file set that was committed in X/B@r1
#

expand(f_1, of_3) = {foo, bar, baz}

(that is, we expand against the baserev)

Advantage: this always works (there are no conflicts by construction)

Such results would be hard to explain to casual users, and therefor not an
preferable option as well.


What would you "expect"?:)

Clearly option b. It's the least astonishing result for this admittedly
difficult problem.

Thanks again, Marcus. It took me two days and a couple of reads to (hopefully
mostly) comprehend your great description. You maxed out the limits of this
limited communication channel. Impressive.

Cheers,
Pete


--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-buildservice+owner@xxxxxxxxxxxx

< Previous Next >