In no particular order...

Short term:

    Write tests for isProperChild() in tools/workspaces.py

    Add an option to create the folderish objects up to the deployment
    target by chosing the portal type.

    Remove cp_container filtering in various places.

    Be accurate with regards to the "elements deployed" when an incremetnal
    deployment happens.

    Add detailed instructions for all operations of the workspace
    (esp. explain the differences between partial and full
    publishing).

    Deal with workspace references (scarecrows). The idea was to put
    them in the workspace that contains the staged equivalent of the
    deployment path, so that the mantainers of that area wouldn't
    accidentally put objects in there that would conflict with the
    objects of the sub-workspace, or would be wiped out when the
    sub-workspace is deployed, but they get left behind if deployment
    areas change or workspaces are deleted... The definitive solution
    will probably take the form of template modifications so that the
    folder_contents view alert the user about the status. Or maybe a
    folder tab that only shows up on the deployment area saying "Don't
    put objects here!" and links to a template explaining the
    situation.

    Don't allow partial publishing of a workspace that hasn't been
    fully published yet.

    Don't store tools.workspaces.SourceStageInfo instances inside
    deployed objects. Calculate the source stage instead of storing it
    inside the object. DONE. Class remain for backward compatibility.

    Allow saving of removed version data, to be restored later.

    write tests for StagingArea.getLastMovementsAndModifications() DONE

    write getLastMovements() using getLastMovementsAndModifications()

    implement VersioningTool.isResourceChanged() with
    repo.isResourceChanged() and a check for objects modified in the
    current transaction. We can do this reliably if no subtransaction
    has happened yet, and we can bail if it has.

    With the above, make VersionTool.maybeCheckin only check objects
    in if they have been really modified. This will give us partial
    publishing without querying the catalog by just diffing two tag
    trees

    implement subtransaction commit for publicaction.

Long term:

    Add an option of absorbing the objects at the destination into the
    staging area as a label (Reverse Deployment)

    Add an option of absorbing and removing the objects from the
    superstage (the source stage of the destination folder)

    Add a "progress meter" so when you click on 'publish', a html
    dialog window prompts.  We could pass a callback to RESPONSE.write
