I can give a quick introduction how I structure my ]project-open[ Code, which include OpenACS obviously.
- There is the main repository which includes the directories of ACS_ROOT, but no packages.
- Packages are configured using a pkgs-list.txt file, which tells checkout-modules to get the packages as submodules
- I usually have a branch for the main repository for each client / installation. This way I can point to special commits in the packages, depending on the client.
- If I make changes to a package for a client, I usually create a quick branch for that feature in the package and point to it from the clients main repository branch. Once fully tested and in production I merge the branch back to master for the package.
- Whenever I work for a client on a package, I make a pull from master for that package to incorporate all the latest changes.
- Any change to a package which is client specific is a very bad idea and will result in myself kicking myself and moving this code into a client package, utilizing any of the methods for customization (Paramaters, Callbacks).
- There is an update-code.sh package which upgrades to the latest version for the client (e.g. If I released code from my dev system and want to update the demo system). This is actually a link from the admin pages.
- there is an addition update-submodules.sh code which updates my dev system to the latest version of the submodules.
This workflow pretty much covers what Gustaf mentioned under the first 5 bullet points.
In addition to that I maintain one installation where I have scripts that pull the remote code from the ]project-open[ CVS repository clone into my package repositories, something I dread once per quarter (or so). This basically is updating my (heavily changed) code base with the latest changes done in ]project-open[. This last part though is more of interest if you keep your own Cloned repositories from the OpenACS repositories if you don't have the ability to commit all your code back (for whatever the reason).
If you have questions on the workflow, let me know. The update-code / update-submodules would be the equivalent to "update from repository" which the APM packages try to do.