Forum OpenACS Q&A: Re: How can I find the code that picks up packages from cvs?

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.

Malte, do you have the switching code and refetching code of following bullet point implemented in the package manager?

- users who want to adapt the code: it would be nice to switch from a "tar checkout" to a "git checkout" via a click in the package manager and to contribute code back also via package manager.

do you use just branches or as well tags? if one pulls via branches one might get work in progress rather than "releases".

is there any reason beyond historic ones that you us git submodules and not subtree?

Nope, instead i have a "update-code.sh" which is being called from a new link in the APM to update to the latest code of the master package. This would in turn update all submodules to the corresponding versions.

In theory though adding the link to check out the master for each submodule should be fairly easy, yet it isn't really the switch from tar checkout to git checkout that is mentioned above. It would require a git submodule to be in place.

I only use branches to be honest as I import the tags from CVS (the code which moves CVS code to git adds branches and TAGS) and I don't need additional tags for my workflow, especially if you work with submodules and point to actual commits for each package.

As for subtree, I actually started with subtree (and still have a version with subtree in place). Yet I ran into issues with custom packages with client specific code and the main repository which contains all the subtrees and keep that in sync with the various branches for development, testing and production. Ultimately I gave up and switched to submodules, never looking back. But I do have code which transforms ]project-open[ and OpenACS into ONE repository using subtree as well (if that is of interest).