<snip> 1) "Code Collisions." - Developers overwriting each other's work. 2) Partial updates - Right now, we have new pages for marketing content that are held up because we don't have our new features for the application done yet. So we can't update marketing pages without updating the app at the same time, (one ZODB) unless we directly update the production servers. (Eeek!) <snip> Forgive me if this is overly simplistic, but these problems can both be addressed or at least worked around by using versions, no? Each developer should have his/her own version object. To lock the object (and solve #1), a developer just needs to open it and click change. Then to unlock whatever was worked on and commit it, save the changes to the version. Granted this means only one person can work on an object at one time. This can be worked around by proper modularization of your app. Also, developers need to remember to save their version changes so that others can work on those objects too. This also has a side benefit of letting you document your changes in a more meaningful way. Also, an entire set of changes can be rolled back if it breaks something. #2 is more about what versions were designed for. Just work on the app code in a version and don't commit it until it's ready. Granted this assumes that you have sufficiently separated the data, layout and code and aren't using a lot of external methods. If this isn't a possible solution, I would just create a production version of the feature in one folder that might not be complete but can be updated, and work on a second copy in another folder that isn't accessible to everyone yet. If this won't work please elaborate on your design and maybe someone will have better idea. Good Luck! -Casey Duncan