History for WhatGoesWhereAndHow
??changed:
-
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, !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",
http://lists.zope.org/mailman/listinfo/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",
http://lists.zope.org/mailman/listinfo/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.