Forum OpenACS Development: Re: What version control system (SCM) does OpenACS use now, still CVS, or Git?

3: Re: What version control system (SCM) does OpenACS use now, still CVS, or Git? (response to 1)

Posted by Andrew Piskorski on 10/18/23 06:43 PM

What about custom websites built using the OpenACS toolkit, what version control approaches have folks been using lately?

I may be starting a new (private) intranet soon, and I want to use Git for that, not CVS. I'll have to think about how to best integrate that with the OpenACS 5.10.x branch code, so I'm curious about others experiences with custom sites and Git.

I am definitely inclined to have just one Git project, with everything organized in directories underneath. In Git-land I think people call this a "monorepo". This is apparently less common than using lots of separate little Git projects, which I find strange, as lots of separate little projects makes things like re-factoring code across them much worse. But maybe they have some good reason for disliking "monorepos"...

So far, my limited experience using Git (and previously Mercurial) with Naviserver is that these new-fangled distributed version control systems are excellent if all your commits follow a nice clean tree structure. If everything I've committed locally is suitable for pushing upstream and merging, Git makes that easy, it's great.

But if I (foolishly?) commit a mix of good patches and private local-only hacks in my same local Git repository, sending only the good patches upstream for merging is a confusing mess. So far I've avoided that by never committing local-only customizations in the Git repository I use for pushing patches upstream. But I'm sure I'll mess that up at some point, and need to learn about whatever arcane tools Git provides for untangling that, and what approaches expert users recommend.

4: Re: What version control system (SCM) does OpenACS use now, still CVS, or Git? (response to 3)

Posted by Josue Cardona on 10/19/23 08:41 PM

Hi, we use git for our main repository and I can say that it is a great tool to have in our belt, and while it might be a Swiss army knife, as long as you start with the main and regular approach I can say go for it.

One of our approaches is using GitFlow, which provides shortcuts to the main commands you want to use in your project and allows a more consistent structure. Some people might not like it but it works in our case (http://datasift.github.io/gitflow/IntroducingGitFlow.html).

The other approach we use is using submodules for our custom packages, and while that is a little more involved in the process of maintaining different repositories for each package, it helps with handling the different versions for each project, that way you can have let's say custom-package 1.0 for project A, but if you need to reuse that package for project B and you might need to make some changes you can either create a branch on that submodule and never merge it to the main branch and keep using it for project B, or do a merge to main/master and use it in the other projects as well.

One thing for sure is that some merges are going to be easy to do, but if there is a merge conflict that's where the fun begins. While there are some UI tools (https://tortoisegit.org/) I only use the command line and a lot of coffee.

5: Re: What version control system (SCM) does OpenACS use now, still CVS, or Git? (response to 3)

Posted by Keith Paskett on 10/19/23 11:57 PM

My approach:

I use some tcl scripts which capture information about git repositories in a given local directory. Then I can check out and synchronize multiple local git repositories between developer, staging, and production sites. With one command I clone or synchronize the OpenACS core, any custom packages for a given site, and a custom page_root directory. I found git sub modules to be too restrictive.
They are available at: https://bbs.logansw.com/projects/TOOLS/repos/git-sync/browse

- git-info.tcl: creates a text file containing information about all git repos under the current directory.
- git-diff.tcl: lists the differences between the current directory and a git-info file
- git-sync.tcl: clones or updates local repos to match a git-info file.
- git-status.tcl: lists basic info about local repos; branch, tag, local changes.

I use tags for release-ready code and tend to put those on directly on the release branch rather than merging back to the main/master branch. I also usually create forks of vendor or OpenACS community packages that I use a lot. Then I create tags on those forks to ensure consistency across all of my developer's installations.

7: Use non-core packages from which branch, main or oacs-5-10 ? (response to 3)

Posted by Andrew Piskorski on 12/01/23 10:09 PM

I plan to use the the OpenACS 5.10 branch from Github. For the non-core packages, which branch of those should I use with OpenACS core 5.10? My guess is that if the package has an oacs-5-10 branch tag, I should use that, and if it does not, I should use main. Does that sound right? There are sometimes other non-branch tags though, like openacs-5-10-compat, so I'm not sure.

Checking some (not all!) of the non-core packages, these do have an oacs-5-10 tag, which I think (but did not check) is always a branch tag:
xotcl-core, xotcl-request-monitor, xowf, xowiki, xml-rpc, acs-datetime, acs-events, attachments, boomerang, bulk-mail, calendar, categories, contacts-lite, file-storage, forums, general-comments, news.

But these do not have the oacs-5-10 tag:
bug-tracker, cronjob, dbm, file-manager, messages, monitoring, project-manager, redirect, ref-currency, ref-us-states, ref-us-zipcodes, timezones, s5, schema-browser, site-wide-search, soap-db, soap-gateway, tsoap, version-control, webmail-system, workflow.

8: Re: Use non-core packages from which branch, main or oacs-5-10 ? (response to 7)

Posted by Antonio Pisano on 12/05/23 02:14 PM

Indeed, you should expect the latest release branch to be available only for those packages that are officially supported.

For other packages, the main branch (which translates from the cvs HEAD) , is the place where the latest code is found.

The *-compat and other tags are translated from cvs and they refer to the OpenACS convention explained at https://openacs.org/doc/cvs-guidelines.html

Keep in mind that the oacs-5-10 branch is currently used as development branch, hence you should expect bleeding edge code from there now. For a more stable codebase you may prefer to stick with one of the release tags.

Hope this helps

Antonio