From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Tom=C3=A1=C5=A1_?= =?UTF-8?Q?=C4=8Cech?= Subject: bug#20137: number of generation doesn't always rise monotonically Date: Mon, 23 Mar 2015 00:40:51 +0100 Message-ID: <20150322234051.GE3826@venom> References: <20150318173550.GE525@venom.suse.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JBi0ZxuS5uaEhkUZ" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45676) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZpUP-0006VP-IE for bug-guix@gnu.org; Sun, 22 Mar 2015 19:41:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZpUM-00088K-C2 for bug-guix@gnu.org; Sun, 22 Mar 2015 19:41:05 -0400 Received: from debbugs.gnu.org ([140.186.70.43]:43060) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZpUM-00088E-8B for bug-guix@gnu.org; Sun, 22 Mar 2015 19:41:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YZpUL-00009q-SR for bug-guix@gnu.org; Sun, 22 Mar 2015 19:41:02 -0400 In-Reply-To: <20150318173550.GE525@venom.suse.cz> Sender: "Debbugs-submit" Resent-Message-ID: Content-Disposition: inline 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: 20137@debbugs.gnu.org --JBi0ZxuS5uaEhkUZ Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Sorry, for some reason I didn't get any e-mail and noticed only closing the bug. I'll subscribe to bug-guix ML to prevent it. > That=E2=80=99s expected, yes. What makes you think it=E2=80=99s a proble= m? First, it was conflicting experience with what you were saying on IRC. User experience was a bit confusing because the behaviour seemed unexpected. >When implementing that, there were several possible choices: > > 1. Upon rollback to N, remove all generations above N. Rejected > because it gratuitously prevents useful use cases. > > 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 rollin= g back > from P+1 would bring you back to P instead of N. I can't understand this reason. It doesn't look like valid reason to me, but only consequence of current implementation. It seems that you don't store information about what was the previous generation and that is whole point. > 3. The current behavior. > >See >for part of the discussion. Thanks for looking that up! >Perhaps we can eventually move to an actual tree structure where the >nodes can be named whatever. Until now I thought that's how generations >work, and are just named after integers for identification purposes. Yes, I had this in mind as well. >I agree this would be the right thing for a real undo mechanism. Exactly! >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 haven't met such situation either (yet). >I=E2=80=99m concerned that this would add both code and user interface >complexity for mostly hypothetical use cases. WDYT? Yes, it would surely add some more code and would be demanding for creating good visual represantation for users, but it could also be much closer to behavior user would expect. And that is something which makes tools to be natural to use. Thank you all for your comments. S_W --JBi0ZxuS5uaEhkUZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUPUwEACgkQ37XrCapiVCM3oACfRIELL5FX4CRIbsLNntGV0HBZ SvgAn2SXlJVabplObRPhHSb4C+q3jiCX =vDgF -----END PGP SIGNATURE----- --JBi0ZxuS5uaEhkUZ--