From: ludo@gnu.org (Ludovic Courtès)
To: Andreas Enge <andreas@enge.fr>
Cc: bug-guix@gnu.org
Subject: Re: Rollback problems
Date: Thu, 24 Jan 2013 21:52:59 +0100 [thread overview]
Message-ID: <87bocel2vo.fsf@gnu.org> (raw)
In-Reply-To: <87mwvystku.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 24 Jan 2013 12:34:25 +0100")
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
next prev parent reply other threads:[~2013-01-24 20:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 20:48 Rollback problems Andreas Enge
2013-01-23 22:58 ` Ludovic Courtès
2013-01-23 23:17 ` Andreas Enge
2013-01-24 11:34 ` Ludovic Courtès
2013-01-24 15:33 ` Alex Sassmannshausen
2013-01-24 15:59 ` Ludovic Courtès
2013-01-24 20:52 ` Ludovic Courtès [this message]
2013-01-25 2:44 ` Nikita Karetnikov
2013-01-25 13:54 ` Alex Sassmannshausen
2013-01-25 14:48 ` Andreas Enge
2013-01-25 14:53 ` Ludovic Courtès
2013-01-27 17:05 ` Ludovic Courtès
2013-01-28 22:10 ` Andreas Enge
2013-01-28 22:44 ` Ludovic Courtès
2013-01-25 3:08 ` Nikita Karetnikov
2013-01-27 17:06 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bocel2vo.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=andreas@enge.fr \
--cc=bug-guix@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).