Forum OpenACS Development: GitHub repo is nicely structured

Collapse
Posted by Mark Aufflick on
BTW, whoever setup the GiHub repo, I love how the non-core packages are all separate repo. I can just fork the core repo, then add the non-core packages I need as submodules into /packages.

That way any site-specific changes can stay in my forks, I can pull in upstream changes and push generally applicable fixes back up (or submit patches - whichever is preferred).

Is that the model that is envisioned?

Collapse
Posted by Victor Guerra on
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,

Collapse
Posted by Mark Aufflick on
Good to know thanks. Can I ask you to add the edit-this-page package to the script?
Collapse
Posted by Victor Guerra on
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.

Collapse
Posted by Mark Aufflick on
Hi Victor, a few more modules please :)

acs-content
acs-interface
acs-mail
acs-util
workflow
bug-tracker
feed-parser
news-aggregator
ratings
skin
version-control

I've also made a little script to make it easy to add packages via submodules. If you're ok with it, I'll do a pull request to add it to the parent git repository. It only makes sense if you're using git, so no point adding it to the main cvs repository I'm thinking.