Forum OpenACS Development: CVS monitoring for OpenACS: fisheye.openacs.org

Dear contributors,

On behalf of the OCT, Victor Guerra and I provided for monitoring of our CVS repository based on Atlassian FishEye (see http://www.atlassian.com/software/fisheye/):

http://fisheye.openacs.org/browse/OpenACS/

(or simply http://fisheye.openacs.org/).

Special thanks go to ...

... the Institute for Information Systems and New Media (Vienna University of Economics) for hosting.

... and Atlassian for licensing their product to us under their Open Source Project License programme (http://www.atlassian.com/opensource/).

Enjoy!

Hi Stefan,

Out of interest (because I'm thinking of using FishEye myself), how long did it take for FishEye to import the whole repository and how much disk space does it need?

Thanks.

Mark,

I just noticed that our virtual machine hosting fisheye became victim of a renegade fsck scrambling. currently, the
machine is in an unbootable state.

we hope to recover the fisheye service in the days to come.

as for your questions:

- fisheye is not that demanding in terms of disk space. it depends on the mode of operation and this, in turn, depends on your target SCM repository. In case of CVS, a local replica of the repository is necessary (or simply fisheye needs to be colocated with cvs). There is no pserver et al. support. SVN is supported in remote mode. the official recommendation is that your fisheye hosting system offers 3 times the size of your repository (in the cvs case).

- initial import is time-intensive. The OpenACS cvs history took 18 hours to be imported by fisheye (according to victor). it might be much less for smaller-scale repos ...

//stefan

I think it may be down now as of 1800z on 29th November 2012.

I fired up fisheye again. It turned out that the JVM (6.0_24-b24) crashed on Nov 29, around 10pm, because of a VM-internal assertion being violated:

# Internal Error (safepoint.cpp:300), pid=25655, tid=140048142944000
# guarantee(PageArmed == 0) failed: invariant

I won't invest any time to find the root cause. For now, I updated the JVM to a more recent patch version. Let's see whether this works. If not, I will attempt a more progressive upgrade of both fisheye and jvm.

//stefan

fisheye is up and running again (has been for the last 20 hours).

//stefan

Jim,

It does, we track/monitor the XOTcl/NX git repository using fisheye: http://fisheye.openacs.org/browse/nsf

//stefan

Jim,

the github sync is done currently "manually" one-way. The openacs.org infrastructure depends currently on cvs (apm generation, upgrade from repository, ...), all documentation (official docs, wiki) address the repository, so this move would be much more work than just altering the SCM. It is not clear, who has to time to do this.

Up to my partial knowledge there is no detailed description of the dependencies and the exact process. Part of the work is always to find the bits and pieces from the source code.... at least for me.

As a rough picture: the cvs guidelines describe the required tags for every release. In a nightly build process, the apm builder iterates over a list versions (OpenACS releases), checks these out based on the tags and builds fresh .apm files for every release.

Update-from-repository queries the openacs.org based on the installed release of the client installation and gets the list of packages available for this release. By comparing the version numbers the local installation figures out what apms are offered for an installation.

It happens from time to time, that update from repository is broken. It happens e.g. when someone increases e.g. the major version from OpenACS without telling the apm generator, that this happened, or when some does not tag time files properly.

Non-core packages are not different from core-packages. There is no magic for determining the compatibility, this works just via cvs tagging: a developer has to tag a version of a package to be compatible with a release. Normally, it is a good advice to create these versions of the packages in the same branch as the major release of openacs (e.g. oacs-5-7) to allow partial fixes there.

The programmatical changes are only required on the main repository part (openacs.org). Everything done with cvs can be done with git as well, sometimes maybe slightly different. One has much options with git. Do we want/need submodules? What kind of workflows do we want to support, do we recommend? The biggest piece of work is finally documentation. At the end, if we would do everything the same way as before, is the change worth the effort?

We have done to move to git for our learn project several years ago, victors repos are more or less a byproduct of this. We have changed our development workflows as well several times. We have now a feature-branch oriented development, which is for larger projects the way to go, when active development is happening. we have rather the fear that our code base is getting to far apart from plain openacs. however, the interests of an release manager are often different from the interests of an developer.