Hello,
So Andreas and I discussed this IRL–we happen to be in the same local
GGUUG[*]. Here’s a summary.
Issues were:
1. Should generations from which we roll back be kept?
2. If not, should they be deleted directly after a successful
roll-back, or just when a new diverging generation is built?
3. More generally, should the history of generations be linear, or
should it be a DAG like Git commits?
Regarding (3), it seems that a linear history not only simplifies the
implementation, but also the user interface, while covering most
practical use cases.
Having agreed on linear history, it seems that (a) the current behavior
is broken because roll-backs don’t actually follow the history, as
illustrated previously, and (b) the generation from which we are rolling
back must be deleted.
Let me illustrate. Suppose these generations:
A ------> B ------> C
When doing a roll-back from C, one should obviously get back at B. At
that point, C would still be available. Keeping it around means that
users can easily switch back to C if B turned out to be less appropriate
(this answers questions (1) and (2)).
Once at B, installing or removing packages would delete C, thus allowing
its generation number to be reused, and create a new generation C’ with
the same generation number as C:
A ------> B ------> C’
At this point, switching back to C is no longer possible.
Thoughts?
I’ll implement that if there are no objections.
Ludo’.
[*] GNU Guix United User Group
