Once you've reviewed the wiki page Russ noted, a few things to keep in mind:
In the AVM (the repo implementation that stores content in web project), each sandbox is actually it's own independent content repository, where certain repositories (user sandboxes, temporary workflow sandbox used for staged specific versions of assets for review or timed submission and deployment to staging) shared content with other sandboxes (ie, share the current version of assets in staging) via a layered directory (and, of course, can share data with any other repository in any other Web Project and any version of that data - files or directories - via additional layers).
Now, each repository - and each snapshot of a repository - can be incrementally deployed to a remote file-server or snapshot. You can take any user sandbox, any workflow sandbox, any staging sandbox, or any version of a user's sandbox, workflow sandbox, and staging sandbox, and push to wherever you want - easily and efficiently.
Now, in our web app, we give you the option of initiating deployment on the latest snapshot of Staging (and to deploy earlier snapshots, allows you to first revert to make an older version the current version, and then in turn letting you deploy). You can add a custom deploy action to a user sandbox if you want, or you can add deployment as a custom action to be automatically trigger via workflow.
Somewhat infinite in terms of possibilities, though some possibilities require some minor customization of workflow or the GUI. Basically, if you map out a flow of changes, we can ensure a proper organization in terms of sandboxes, deployment, and supporting workflow. Most anything at least from the server should be supported.
Kevin
