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

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

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

Where does the current OpenACS code live? Is it still using CVS, or has it switched to Git or some other version control system?

From the OpenACS Release Status page I think OpenACS 5.10.0 from 2021-09-15 is the current Stable version. Get the OpenACS Source Code points to CVS and the OpenACS 5.10.0 tarball. Fisheye (aka cvs.openacs.org) is showing live activity today, excellent! I'm pretty sure it's reading from the official CVS repository.

Btw, does Fisheye even support Git or other non-CVS SCM tools? Will you still want to use Fisheye if/when you switch away from CVS? Or is there some other Git-centric tool that subsumes Fisheye's features?

The Migration from CVS to GIT page pointed me to Victor Guerra's unofficial Git mirror. The Openacs git repo on Github page is currently mostly empty.

So to answer my own question, I'm pretty sure OpenACS currently still uses CVS.

Any thoughts or links to past discussion on if or when OpenACS will switch to some other system?

2: 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:23 PM

Btw, I've been experimenting with using Reposurgeon to convert some private CVS repositories to Git. There is a learning curve and up-front work, but so far it seems ok. A big old public repository like OpenACS would be harder, of course.

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

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

Posted by Antonio Pisano on 10/20/23 11:42 AM

Dear Andrew,

some work is currently ongoing in order to phase out CVS as version control tool [1] [2]. This is also a long term goal since a while [3]. The main dependency with CVS in our codebase regards rebuilding the *.apm package repository and only really affects openacs.org, as regular instances are not intended to act as repositories on their own.

Replacing the repository build is actually the easy part. More effort is to update the many documentation pages on the openacs.org website and in the acs-core-doc package so that they will refer to Git instead of CVS. This will include writing some new documentation detailing best practices, checking link references and so on. This is also ongoing. It would be nice if this was the chance to update other parts of the documentation as well and clean up obsolete pages (references to aolserver, ancient versions...) but I fear this would take us out of scope.

Concerning the GitHub mirror, this is actually "official", whatever this means and is actually what WU and other users get their code from. Commits are automatically translated from CVS to Git on a daily basis and is "safe for consumption". Because of its nature as a mirror, we currently cannot accept pull requests or move much of our workflows there, but we hope this will change in the near future.

Ciao

Antonio

[1] https://cvs.openacs.org/changelog/OpenACS?cs=oacs-5-10%3Aantoniop%3A20231018085957
[2] https://cvs.openacs.org/changelog/OpenACS?cs=oacs-5-10%3Aantoniop%3A20231018150037
[3] https://openacs.org/xowiki/openacs-todo

9: Re: GIT Submodules (response to 1)

Posted by Frank Bergmann on 11/11/24 11:01 AM

Hi,

Just for your information, ]project-open[ has switched to GIT some years ago. We are running a GitLab instance with a separate repo for every package, because we need to keep some packages private (>100 "customer packages" plus some closed-source packages). Normally we track versions only per package.

However, one of our customers has asked us to maintain release information with versions for all packages.

So we have created a new "packages" repo that contains the ~200 ]po[ packages as GIT "submodules". We've also created a GUI that lists "releases" (commits on the "packages" repo) together with the included commits on the individual packages. That's nothing big, but it's nice to be able to show the users their current release with the specific changes, also linked to the customer's internal bug-tracker with manages the development pipeline. Contact me if you want the code. Also, we've created a GIT pre-commit hook that automatically increases the package version number (per package).

I've heard mixed reports about using GIT submodules in the past, but the negative reports seem to be due to confusion (mental model not matching reality 😊.

Cheers!
Frank