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