WhatGoesWhereAndHow

What Goes Where and How

The repository consists of applications and also directories of elements which are typically shared among the applications. Anyone making additions to the repository must understand the sharing arrangements to know how to properly situate the additions. There are facilities (controlled by checking in recipe files) for managing the interconnections and for directing the destinations for checkin notices. This is all described below.

See CVSAddons for a description of the ingredients and hookup of our special CVS provisions that implement the sharing and notifications, etc.

Organization

The short story re organization is that only application-specific stuff should go directly in the application sections of the repository. Lots of stuff should wind up in Packages (and get linked into the application(s) where its used via the CVSROOT/repolinks), except for Zope products which go in Products.

Products

Zope python-based extension packages. The Zope repository section links to the standard products from Zope/lib/python/Products.

Packages

Non-Product python packages used in the various repository applications.

You would generally expect to add to Packages when adding a substantial element to any application, and link the package in to the application skeleton.

Docs

General Zope-related documentation, and application specific documentation directories.

Various Applications

Zope, CMF, StandaloneZODB, ZEO, and others as they emerge. These directly contain the application-specific elements, plus links to the Packages, Products (in the case of Zope), and Docs for sharable elements.

Cruft

shared stuff that doesn't have a proper place in the other official places.

(There is also a few legacy items: Zope2 is an old name for the Zope checkout, no longer being actively maintained. Releases was a temporary provision - it has been redirected, to support old checkouts, but will soon be removed.)

Sharing of Repository Elements

Repository element sharing is arranged using symlinks in the repository. (We can't use standard CVS modules due to severe deficiences, described in http://mail.zope.org/pipermail/zope-announce/2001-August/000517.html .) Those symlinks are governed by a textual list in the CVSROOT bookkeeping directory, CVSROOT/repolinks. People with checkin privileges can change the sharing structure by changing this file. You should really know where things belong before messing with the structure - if you are unsure, contact the people on mailto:[email protected] (so everyone can get filled in on the answers), or contact the mailto:[email protected] directly if you're shy.

The CVSROOT/repolinks file has comments at the top describing the format.

The CVSROOT/adjustlinks.py script is automatically invoked to apply the link map prescribed by repolinks. The docstring for LinkMap.assert_links() method details the actions - here's a current (08/07/2001) snapshot:

        """Impose the links specified by the recipe, removing preexisting
        links that are not specified in the map.  Specifically:

          - Add prescribed links that are absent, when there's no non-link
            file in the way.

          - Adjust already-existing links that don't point to the prescribed
            place - so we can use the recipe file to redirect existing links.

          - Remove links that are not prescribed.

          - Do nothing for links that already exist as prescribed.

          - Warn about prescribed links that point nowhere.

          - Warn about prescribed links that cannot be created because the
            indicated containing dir does not exist.

          - Reiterate attempts until all are done, or no more progress is
            being made - so it's not a problem for links to be dependent on
            others in order to be situated.

          - Delete prescribed links that point outside the repository.

          - Produce output about all the actions."""

The warnings and info messages resulting from application of the script are sent to the digicool-cvs mailling list.

Checkin Notices

Checkin notices about all checkins are dictated by another script we've added to CVS central bookkeeping, CVSROOT/traffic_table.py . Using entries in that table you can cause checkin notices for a particular section of the repository to be directed to any email addresses - typically we send them to mailling lists. Notices for any checkins not corresponding to a particular entry are sent to the zope-cvs list.

Note that the checkin mechanisms account for the repository symlinks dictated by repolinks. Ie, all relevant entries for an element will be triggered, even if that entry contains the directory where the checkin was made only indirectly, due to symlinking.