Menu ▾ ▴

#439 Easier destroy for background jobs

workingwiki
open
nobody
None
5
2013-11-05
2013-11-03
Jonathan Dushoff
No

Discussion

  • Jonathan Dushoff

    Jonathan Dushoff - 2013-11-03

    Having to click twice for Destroy is a workflow issue when debugging projects with background jobs (especially since the second click is hard to shortcut). Ideal would be do revoe something from the list with a single click, but not actually destroy it until it is garbage-collected. This would require having an option to browse deleted background jobs for a project, so that you could undo a careless delete.

     

  • Andrei Akhmetzhanov

    Andrei Akhmetzhanov - 2013-11-03

    (just noticing that to keep the deleted background jobs might require much of the disk space. I am writing this because it is usually the reason for me to remove some of them)

     

  • Lee Worden

    Lee Worden - 2013-11-04

    On 11/03/2013 12:33 PM, Jonathan Dushoff wrote:

    Having to click twice for Destroy is a workflow issue when debugging
    projects with background jobs (especially since the second click is hard
    to shortcut). Ideal would be do revoe something from the list with a
    single click, but not actually destroy it until it is garbage-collected.
    This would require having an option to browse deleted background jobs
    for a project, so that you could undo a careless delete.

    I haven't added the shortcuts yet, but my expectation is that in the
    1.21 wikis, the confirm as well as the initial action will have keyboard
    shortcuts. Does that help? I'd rather not write background jobs
    garbage collection and deleted-job browsing.

     

  • Jonathan Dushoff

    Jonathan Dushoff - 2013-11-04

    Keyboard shortcuts would certainly help.

    I had an idea for how the browsing could be made easy, but the whole comment was based on the assumption that we already had garbage collection. Is it a problem that we don't?

     

  • Lee Worden

    Lee Worden - 2013-11-04

    We have garbage collection for preview directories, though it may not be
    working right. But it doesn't do background jobs, on the assumption
    that they should persist until someone deletes them explicitly.

     

  • Jonathan Dushoff

    Jonathan Dushoff - 2013-11-04

    I guess it's tricky. Certainly, crap could accumulate. The question is: can we outgrow it? Or monitor it manually?

    Given that we don't have it yet (and haven't desperately needed it), we should postpone considering the quick-delete possibility.

     

  • Andrei Akhmetzhanov

    Andrei Akhmetzhanov - 2013-11-05

    I think it is the same kind of issue as to keep the track of all changes on the WW page including the results for the project-files, no?

     

  • Lee Worden

    Lee Worden - 2013-11-05

    On 11/04/2013 04:01 PM, Andrei Akhmetzhanov wrote:

    I think it is the same kind of issue as to keep the track of all changes
    on the WW page including the results for the project-files, no?

    I don't think it's the same. A background job is a copy of the
    project's working directory (and maybe other projects' as well), and we
    have code that copies them and keeps track of where they are.
    Jonathan's proposal would require a way to distinguish jobs that are
    marked for deletion from ones that aren't.

    Keeping track of past values of project files would require some
    different kind of system, I think. Probably checking them into a
    revision control system after every make.

    By the way - WW's archived project files feature gives you a partial way
    to do this, if there are particular files whose history you want to record.

     

Anonymous
Anonymous

Add attachments
Cancel