From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Sassmannshausen Subject: Re: Rollback problems Date: Fri, 25 Jan 2013 13:54:51 +0000 Message-ID: <1359122091.2545.2.camel@Nokia-N900> References: <201301232148.46744.andreas@enge.fr> <87mwvzsdzt.fsf@gnu.org> <201301240017.55013.andreas@enge.fr> <87mwvystku.fsf@gnu.org> <87bocel2vo.fsf@gnu.org> <87622mhthi.fsf@karetnikov.org> Reply-To: Alex Sassmannshausen Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:58619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TyjkD-0004zJ-TQ for bug-guix@gnu.org; Fri, 25 Jan 2013 08:55:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tyjk7-0007CH-J7 for bug-guix@gnu.org; Fri, 25 Jan 2013 08:55:01 -0500 Received: from mail-wg0-f49.google.com ([74.125.82.49]:38691) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tyjk7-0007CB-Ci for bug-guix@gnu.org; Fri, 25 Jan 2013 08:54:55 -0500 Received: by mail-wg0-f49.google.com with SMTP id 15so253852wgd.16 for ; Fri, 25 Jan 2013 05:54:54 -0800 (PST) In-Reply-To: <87622mhthi.fsf@karetnikov.org> Content-ID: <1359122090.2545.1.camel@Nokia-N900> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: bug-guix@gnu.org > > 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. I agree too. Plus, it seems like a neat mechanism. I guess a generation would only be destroyed at a junction, not when moving back and forth in straight lines. A ------> B ------> C You could travel from C back to A and back to C without having to re-install packages... Looking forward to seeing it implemented. Alex On Fri, 25 Jan 2013, 02:44:39 GMT, Nikita Karetnikov wrote: > > 3. More generally, should the history of generations be linear, or > > should it be a DAG like Git commits? > > If the latter is the case, then we can probably use a simple tree.  Here > is a related link: [1]. > > > Regarding (3), it seems that a linear history not only simplifies the > > implementation, but also the user interface, while covering most > > practical use cases. > > I agree. > > > 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. > > I like the idea. > > Nikita > > [1] http://learnyouahaskell.com/zippers#a-very-simple-file-system