Issue 2436 rollback --patches takes ages before first prompt

Title rollback --patches takes ages before first prompt
Priority bug Status needs-diagnosis/design
Milestone Resolved in
Superseder Nosy List bfrk, gh
Assigned To
Topics Performance

Created on 2015-02-10.23:11:50 by bfrk, last changed 2022-04-12.13:37:20 by bfrk.

msg18063 (view) Author: bfrk Date: 2015-02-10.23:11:48
1. Summarise the issue (what were doing, what went wrong?)

> time darcs rollback -p'compress patch data before sending'

in a clone of the darcs screened repo runs for over 2 minutes without
giving me any feedback. A matching patch is near the top, only a handful
of patches back.

2. What behaviour were you expecting instead?

That I quickly get a prompt asking me about the last (in application
order) matching patch.

3. What darcs version are you using? (Try: darcs --exact-version)

2.9.9 (+ 253 patches)

4. Further note

There is a patch that depends on the one I want to roll back and this
other patch does not match the pattern. At first I thought the pattern
is not unique and rollback tries too eagerly to calculate all
dependencies of a very old patch. But not so, darcs log -p'compress
patch data before sending' returns quickly and lists one matching patch.
msg18384 (view) Author: gh Date: 2015-04-20.14:57:48
Looks like rollback -p scans the whooole history before showing the
prompt.  In a sense rollback is similar to obliterate in the patch
selection process. (With the difference that obliterate does not look
for patches older than the last tag.)

Hence I wonder why rollback has to show us the total number of
selectable patches in the selection prompt? If we change this setting
the bug is fixed.
msg18750 (view) Author: gh Date: 2015-09-22.13:56:01
The fundamental issue seems to be that the SelectChanges exclusively
works with FL's, because Darcs.Patch.Choices does. The solution, then,
would be to generalize Darcs.Patch.Choices to work with RL's also (which
makes sense for "undo" operations like rollback, obliterate).
msg19588 (view) Author: bfrk Date: 2017-08-14.10:31:24
I have been looking into Darcs.Patch.Choices and made some experimental
changes to support RL as well as FL. I found that some of the functions
can be easily generalized while for others this is hard. Thinking a bit
more about the reasons for that I began to ask myself why PatchChoices
does not use a zipper-like structure. Currently pcsFirsts and pcsLasts
are both an FL of (labeled) patches. I wonder if it makes sense to turn
pcsFirsts into an RL; then the whole thing can be made to work in a more
symmetric manner. I am also thinking about pulling things like
WhichChanges from UI.SelectChanges into Patch.Choices.
Date User Action Args
2015-02-10 23:11:50bfrkcreate
2015-04-17 20:03:33ghsettopic: + Performance
nosy: + gh
2015-04-17 20:46:14ghsetmilestone: 2.10.0
2015-04-18 17:39:18ghsetmilestone: 2.10.0 -> 2.12.0
2015-04-20 14:57:50ghsetmessages: + msg18384
2015-09-22 13:56:03ghsetmessages: + msg18750
2017-08-14 10:31:26bfrksetmessages: + msg19588
2020-07-31 20:49:25bfrksetmilestone: 2.12.0 ->
2022-04-12 13:37:20bfrksetstatus: unknown -> needs-diagnosis/design
priority: bug