Forum OpenACS Development: GitHub repository

Hi all,

It's been a while (my last post seems to be 2009)!

I'm migrating some of my much-neglected OpenACS sites to a new host (linode) and thought I'd have a go at upgrading them while I'm at it, using debian and the debian aolserver packages.

So I came across the openacs github account which seems to be pretty up to date and it would suit my workflow well to use that, but I can't find any reference in the forums about if that is now the primary or if it's a mirror if it's kept in sync automatically etc.

It's fun to be dabbling in OACS again, and all without having to compile my own AOLServer!

Hi Mark,

Last year I wrote a script for migrating the OpenACS CVS repository ( based on http://cvs2svn.tigris.org/cvs2git.html with some modifications ) basically for experimenting and for my own convenience. And I figured it would be nice to have an OpenACS organization in GitHub in case OCT decides to forget about CVS and migrates to GIT ( There is another project out there named openacs as well and it would have been unfortunate if they did register themselves before we did =) ). So far, no decisions have been made by the OCT to migrate to GIT, and I am not sure if there is any intention of migrating, so the CVS repo is the official one ( contributions should go there and so on ). A page in our wiki was created in order to put together some ideas on what migrating would mean to the project: https://openacs.org/xowiki/git_migration .

So by now the repositories on GitHub are ment as pure reference, you can fork them and so on, but nothing will be commited/pulled into.

Regarding the structure of repositories in GitHub, while migrating it seemed more practical to me to have independent repositories for each package and one repository for the core itself, so I went this way, I am glad you like it. Having just one big repository holding the entire code base ( a couple of hundreds of Megas ) would not be practical I guess. Also, this days, the management of submodules has been improved by Git and there are a couple of tools out there that help as well for such administration tasks.

The only "inconvenience" I can think of with this model is when it comes to .LRN applets, lets say, in case you want to install file storage you would have 3 separate repositories to clone : file-storage, fs-portlet and dotlrn-fs-applet; so probably it would be better to combine those three into one repository... but I guess one could live with three separate ones ( this is how we do it anyway with CVS, we have separate modules that one has to check out ).

The script runs on the openacs.org machine and it takes around 15 mins to sync core pkgs, .lrn pkgs, xotcl based pkgs and acs-object-management. If I want to sync an extra package, I just update a config file that contains a list of packages to be synced. If the repo does not exists on github, it is created on the fly, which is nice. When the script is done syncing, everything is mirrored to the GitHub account.

So far, when ever I see some activity on the CVS repo I trigger the script myself, of course one could run it daily but I am not sure if it makes sense right now. Also, if the project ever moves in the Git direction I think it would make more sense to completely leave behind CVS; given the amount of commits we see It would not pay off to maintain both repositories simultaneously.

Best,

Sure! ... I added the package and ran the script. So there you have it: https://github.com/openacs/edit-this-page

Please let me know if you experience any problems with the repo.

That's cool.

Using 5.6+ where you can subtype a package and override single templates etc, that sounds like a perfect way to work.

What sort of sites are you building on OpenACS these days?

Heya Victor...

Could you add ecommerce if not already? (and its deps as specified by ecommerce.info)

-Jim

Thanks Victor... What would go into a "basic usage" doc, and a "best practices" doc? let's see, for basic "get the core" might start something like, This would be a first cut on the openacs user's documentation. It will need filling out.

There is a github repo for openacs core, and also one for each non-core package. One way to start, is get a free github account, and then fork openacs-core, which will appear under your account.

Make sure you have your ssh key in your linux user account, and add the public half of your key to your github account. Once you do this...

You can then git clone the acs-core from your fork to the dir where your service will go. You will then have what git calls a working directory, which also has a "git remote" which is a pointer to your forked repo on github.

Edit the config file (which is in etc/config.tcl) as indicated by docs elsewhere. It's not recommended to add this file to your repo, as it may have passwords in it.

if your config file does not have sensitive information in it, you could commit to the local git repo, and could commit to master, which when you push, will go to your forked repo. If you commit to other than master, you could refrain from pushing that branch, so your config file would not get pushed when pushing your other changes.

Once you have a first cut of your config file, try to start the server. Watch the error log for errors, when they occur, go to the first one to find out what started the throwing of the error, determine and fix the problem, if config file changed, add/commit and repeat until the server will start.

So when will this finally be the official way of contributing to OpenACS? I just ranted on the IRC channel that not having access to CVS is a real pain to those who create patches (and thus have to maintain private forks). Using Github (or any other Git repository service) as the official repository would make things much simpler, and it will help keep patches from dying slow deaths in the OpenACS bug tracker.