Guys:
A super nice way of doing this is to leverage more of the underlying power of the web content store (the AVM).
Remember, each sandbox is actually its own Subversion-style repo. That means in each repo you have file and directory versioning, file and directory branching, and store-level versioning and branching. A web project is really just an arbitrary association of repos, with one call Staging, others named after their user-owners, and another - usually on one or more remote servers - called live. Repos of course sync via AVMSyncService, whether on the same server (done as an action in our default workflow) or separate servers (done via our deployment service).
Each repo also supports layered files and layered directories. By default, user repos (or sandboxes), have a layered directory that points to their local Staging repo (or sandbox). That way, any content committed to Staging is auto-reflected in all other sandboxes.
Why highlight this?
You can create one web project for your common app code. You can do all your dev in a sandbox via CIFS. When happy, you can check in to your local Staging. Before checking into Staging, you can do local snapshot (via our API) against your sandbox for local versioning. We'll make that easier in a few months with a set of command-line tools.
Now, in all your other web projects, what you'll need to do is create a layered directory using our API that points to your dev Staging repo. This means that automatically, all Staging repos in all web projects will instantly be updated with your new code - and, correspondingly, all user sandboxes as well.
In 2.2 Enterprise, we add support for saving a web project as a template, and allow you to quickly create new web projects from a template. What this feature does is create your new web project's Staging repo by BRANCHING the Staging repo of its parent template. Thus, it starts out with a body of content. You can sync as you wish to stay current with updates. A sneak preview of this can be found on our wiki.
This feature can be used in conjunction with layered directories. Create your web project for your code, create a default web project that has a layered directory pointing to the layered code, and then create all your web projects by branching from that template. Viola! You only need to create the layered directory once. Everyone automatically gets its - and all code updates.
This is the same thing we recommend for corporate brand assets and common content libraries as well. Create them in their own separate web projects - they don't actually have to be complete websites themselves. They are just shared resources. Resources we make very, very easy to share via layers.
Take a look under the covers at what really possible at the API layer. It's really, really powerful. We look to expose more of its capabilities in the web client over time in future releases.
Cheers! Have fun discovering … the repo is a powerful thing.
Kevin
