From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#20137: number of generation doesn't always rise monotonically Date: Thu, 19 Mar 2015 09:47:06 +0100 Message-ID: <871tkl8jcl.fsf@gnu.org> References: <20150318173550.GE525@venom.suse.cz> <87k2yedovp.fsf@gnu.org> <87zj7a3udo.fsf@taylan.uni.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYW7X-0006Qo-1g for bug-guix@gnu.org; Thu, 19 Mar 2015 04:48:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YYW7W-000790-8E for bug-guix@gnu.org; Thu, 19 Mar 2015 04:48:02 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:53864) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YYW7W-00078w-4r for bug-guix@gnu.org; Thu, 19 Mar 2015 04:48:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YYW7V-00059Q-U2 for bug-guix@gnu.org; Thu, 19 Mar 2015 04:48:02 -0400 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87zj7a3udo.fsf@taylan.uni.cx> ("Taylan Ulrich \=\?utf-8\?Q\?\=5C\=22Bay\=C4\=B1rl\=C4\=B1\=2FKammer\=5C\=22\=22's\?\= message of "Wed, 18 Mar 2015 21:47:47 +0100") 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: "Taylan Ulrich \"=?UTF-8?Q?Bay=C4=B1rl=C4=B1/Kammer?=\"" Cc: 20137@debbugs.gnu.org taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> 2. Upon rollback from P to N, keep all the generations, but use P+1 >> for the next generation number. Doesn=E2=80=99t work, because roll= ing back >> from P+1 would bring you back to P instead of N. > > Perhaps we can eventually move to an actual tree structure where the > nodes can be named whatever. I agree this would be the right thing for a real undo mechanism. But how useful would it be? I=E2=80=99ve never been in a situation where rollback/switch-generation would be insufficient or inappropriate. I=E2=80=99m concerned that this would add both code and user interface complexity for mostly hypothetical use cases. WDYT? Thanks, Ludo=E2=80=99.