[darcs-devel] make optimize a supercommand

[Ben Franksen]

Guillaume Hoffmann wrote:
> Don't worry, patches pushed to screened (and even reviewed) can always
> be discussed and rollback'ed, there is no problem about that and it
> happened before (unless we are really beating a dead horse…). 

Oh, good. I was mostly worried that you do lots of unnecessary work here.

> Your
> initial suggestion sparkled a reflexion on my side that I should have
> shared when I sent the bundle. So here are the explanations.

Thanks.

> Over time, "optimize" has incorporated distinct operations, some of
> which are arguably more "low-level tweaks" than "optimizations". It
> goes from the basic garbage collection, to repo format changing
> (--upgrade, --pristine), to enabling or disabling patch index, to
> compressing or uncompressing patches.
> 
> All of these transformations are ran with low frequency. The most
> often used are the default one (garbage collection) and --reorder. And
> --http when you administrate a public repo. Yet they are seldom run if
> you compare with record, pull, send, etc. This is my main point about
> saying that enabling simultaneous transformations, as you propose, is
> not that important.

It is not that important, agreed. Still, removing the possibility is not 
something I would do lightly.

> About complexity: Optimize.hs does have more lines of code, and some
> things could be factored, but I believe the module is less complex
> now. It gives a clearer idea of what each subcommand does. Generally
> I'd rather see darcs evolve into larger but more understandable
> codebase this way.

I'll take a closer look at your patch and see if I can agree with this ;-)

> Also some of these transformations could be done silently by darcs
> when running other commands, yet we chose to make the user run them
> manually. In the past, garbage collection was done after each record;
> that was until we discovered that this could break cloning when
> recording in public repos (and it can be slow on big ones). You could
> also reorder patches every time you pull a new tag; however this
> operation is computationally complex. To me it's also a point in
> favour of making each flag a real subcommand.

I like the idea of introducing more automation for the various 
optimizations, but of course we must make sure that this does not collide 
with concurrent remote access.

As for the slowness, have you considered storing a time stamp after each 
optimization somewhere in the repo, so we can avoid doing them on every 
command and instead do them, say, once per day or week, or so? Maybe a good 
idea would be to make the frequency of optimizations an option (with a 
sensible default value) so users can reconfigure it. Instead of (or in 
addition to) time-based scheduling we could also offer "every N repo-
changing commands".

Also, when Darcs decides it is time for an optimization run, it could ask 
the user before it starts, offering to delay it either for another period or 
until the next command. The situation is similar to how modern Linux distros 
handle file system checks on system startup.

> Finally, each subcommand now has a specific help string, whereas
> before this bundle, you had a single wall of text that was supposed to
> explain everything "optimize" did. So +1 for documentation (I'm
> referring to the output of `darcs help markdown` in particular, which
> we may use to generate the future manual).

This is indeed a pretty strong point in favor of splitting it into sub-
commands.

Cheers
Ben
-- 
"Make it so they have to reboot after every typo." -- Scott Adams