number of generation doesn't always rise monotonically

  • Done
  • quality assurance status badge
Details
5 participants
  • Thompson, David
  • Ludovic Courtès
  • Tomáš ?ech
  • Taylan Ulrich Bay?rl? /Kammer
  • Tomáš ?ech
Owner
unassigned
Submitted by
Tomáš ?ech
Severity
normal
T
T
Tomáš ?ech wrote on 18 Mar 2015 18:35
(address . bug-guix@gnu.org)
20150318173550.GE525@venom.suse.cz
Generation number is not always the maximum of all generation numbers
and so generation number is not always monotonic.

Steps to reproduce:

Lets start with on generation N.

1] install some package (you'll have N and N+1)
2] install some other package (you'll have N, N+1 and N+2)
3] delete generation N+1 (you'll have N and N+2)
4] switch to generation N
5] install some package - you'll get generation N+1 again
(you'll have N, N+1 and N+2 again)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUJt3QACgkQ37XrCapiVCPwXQCeMNzliKZNdh8kNQ1wP6Re0eLD
PZEAn36V5vYjCn4JhMh6La9oMwdhPUzQ
=5Dv5
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 18 Mar 2015 21:36
(address . 20137@debbugs.gnu.org)
87k2yedovp.fsf@gnu.org
Tomáš ?ech <sleep_walker@gnu.org> skribis:

Toggle quote (7 lines)
> 1] install some package (you'll have N and N+1)
> 2] install some other package (you'll have N, N+1 and N+2)
> 3] delete generation N+1 (you'll have N and N+2)
> 4] switch to generation N
> 5] install some package - you'll get generation N+1 again
> (you'll have N, N+1 and N+2 again)

That’s expected, yes. What makes you think it’s a problem?

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’t work, because rolling back
from P+1 would bring you back to P instead of N.

3. The current behavior.

for part of the discussion.

Thanks,
Ludo’.
T
T
Taylan Ulrich Bay?rl? /Kammer wrote on 18 Mar 2015 21:47
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20137@debbugs.gnu.org)
87zj7a3udo.fsf@taylan.uni.cx
ludo@gnu.org (Ludovic Courtès) writes:

Toggle quote (4 lines)
> 2. Upon rollback from P to N, keep all the generations, but use P+1
> for the next generation number. Doesn’t work, because rolling 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. Until now I thought that's how generations
work, and are just named after integers for identification purposes.

Taylan
T
T
Thompson, David wrote on 18 Mar 2015 21:52
(name . Taylan Ulrich Bay?rl?/Kammer)(address . taylanbayirli@gmail.com)
CAJ=RwfZiXW848W=1R9tWCgMf91E4aBCBNRrcQh7y-VWwAjV5Fw@mail.gmail.com
On Wed, Mar 18, 2015 at 4:47 PM, Taylan Ulrich Bay?rl?/Kammer
<taylanbayirli@gmail.com> wrote:
Toggle quote (9 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> 2. Upon rollback from P to N, keep all the generations, but use P+1
>> for the next generation number. Doesn’t work, because rolling 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.

+1

- Dave
L
L
Ludovic Courtès wrote on 19 Mar 2015 09:47
(name . Taylan Ulrich "Bay?rl? /Kammer")(address . taylanbayirli@gmail.com)(address . 20137@debbugs.gnu.org)
871tkl8jcl.fsf@gnu.org
taylanbayirli@gmail.com (Taylan Ulrich "Bay?rl?/Kammer") skribis:

Toggle quote (9 lines)
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> 2. Upon rollback from P to N, keep all the generations, but use P+1
>> for the next generation number. Doesn’t work, because rolling 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’ve never been in a situation where
rollback/switch-generation would be insufficient or inappropriate.

I’m concerned that this would add both code and user interface
complexity for mostly hypothetical use cases. WDYT?

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 22 Mar 2015 23:48
(name . Taylan Ulrich "Bay?rl? /Kammer")(address . taylanbayirli@gmail.com)
878ueoy7gd.fsf@gnu.org
tag 20137 notabug
thanks

I think the initial “bug” report can be closed. Feel free to open
another bug or wishlist item if you think something must be done in this
area.

Thanks to both of you!

Ludo’.
Closed
T
T
Tomáš ?ech wrote on 23 Mar 2015 00:40
(address . 20137@debbugs.gnu.org)
20150322234051.GE3826@venom
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.


Toggle quote (2 lines)
> That’s expected, yes. What makes you think it’s a problem?

First, it was conflicting experience with what you were saying on IRC.
User experience was a bit confusing because the behaviour seemed
unexpected.

Toggle quote (9 lines)
>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’t work, because rolling 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.

Toggle quote (5 lines)
> 3. The current behavior.
>
>See <http://lists.gnu.org/archive/html/bug-guix/2013-01/msg00325.html>
>for part of the discussion.

Thanks for looking that up!



Toggle quote (4 lines)
>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.


Toggle quote (2 lines)
>I agree this would be the right thing for a real undo mechanism.

Exactly!

Toggle quote (3 lines)
>But how useful would it be? I’ve never been in a situation where
>rollback/switch-generation would be insufficient or inappropriate.

I haven't met such situation either (yet).

Toggle quote (3 lines)
>I’m 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUPUwEACgkQ37XrCapiVCM3oACfRIELL5FX4CRIbsLNntGV0HBZ
SvgAn2SXlJVabplObRPhHSb4C+q3jiCX
=vDgF
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 23 Mar 2015 10:13
(name . Tomáš ?ech)(address . tcech@suse.cz)(address . 20137@debbugs.gnu.org)
87lhiom5zq.fsf@gnu.org
Tomáš ?ech <tcech@suse.cz> skribis:

Toggle quote (4 lines)
>>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.

[...]

Toggle quote (8 lines)
>>I’m 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.

I’m not sure. My guess is that an undo-style tree would turn out to be
less obvious or more difficult to use.

Currently, understanding what’s going on with M-x guix-generations or
--list-generations and similar is fairly straightforward.

Thanks for your feedback,
Ludo’.
T
T
Tomáš ?ech wrote on 23 Mar 2015 10:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 20137@debbugs.gnu.org)
20150323095024.GF24080@crashnator.suse.cz
On Mon, Mar 23, 2015 at 10:13:13AM +0100, Ludovic Courtès wrote:
Toggle quote (22 lines)
>Tomáš ?ech <tcech@suse.cz> skribis:
>
>>>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.
>
>[...]
>
>>>I’m 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.
>
>I’m not sure. My guess is that an undo-style tree would turn out to be
>less obvious or more difficult to use.
>
>Currently, understanding what’s going on with M-x guix-generations or
>--list-generations and similar is fairly straightforward.

I'm not using emacs for controling guix at all. But I should start - I can see
that is completely different user experience!

Thanks!

S_W
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlUP4d0ACgkQ37XrCapiVCPNbACfXgoj956eOIn+gbp0WgxPuPUb
uJsAnRdPxEM0nDqA+axZTdEZdqZNC4gW
=0EoN
-----END PGP SIGNATURE-----


?
Your comment

This issue is archived.

To comment on this conversation send an email to 20137@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 20137
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch