[Zope-Annce] More CVS shifting

[Ken Manheimer]

We've hit on some snags in the process of using the new CVS
arrangement.  The organization is good, but the use of CVS modules
turns out to be deficient - enough so that we're evaluating a
different scheme to implement the organization.  If we shift to the
new scheme, it will mean having to once again do new checkouts - old
checkouts will not update.

We'd like to scope this out and make the switchover quickly, to reduce
that amount of time that people get settled into the old new scheme. I
figure i'll have evaluated the new scheme by the end of the day, and
(presuming it's ok) will allow another day for word to filter out (and to
prepare things for the shift), implementing the shift on friday, Aug 3.

In the interest of getting CVS-savvy attention to the issues and
plans, i'm sketching out the details of the situation, below.  For those
of you that aren't really interested, the important thing is that you'll
have to (once again) redo your checkouts when the changeover happens,
probably this friday.

The Problems

  The first problem is that structural changes to a module-based
  recipe are not tracked by CVS updates.  If someone adds or deletes
  elements being composed, people with existing checkouts do not see
  them unless they redo the checkout.

  It turns out that people can redo the checkout on top of their
  existing checkout, and it'll preserve local changes, but this is not
  satisfactory, for a few reasons:

    - It requires that updates be of the entire checkout, without the
      option to do just sections.

    - These "updates" have to include all the information of the
      original checkout - you have to designate the server:host:dir
      each time.

  It's just untenable.

  The other problem with modules is that they're invisible to our web
  interface to the repository, ViewCVS (and i expect the same holds
  for alternatives, like cvsweb).  This is a serious drawback for
  those who depend on the web views for discovering what's there, or
  for tracking or reporting changes.

The Proposed Solution

  Instead of using modules, we will use symlinks to knit together the
  composite applications.

  CVS works with respect to the files as they're presented by the
  filesystem.  As far as CVS is concerned, a symlink is the file to
  which it points.  By using doing the composition with symlinks,
  addition or deletions of links is treated just like addition or
  deletion of the targeted directories, so CVS updates will properly
  reflect the changes.  We choose symlinks instead of hard links to be
  explicit about the sharing relationships - to indicate where the
  primary location is, as opposed to the places that share access to
  the primary, using symlinks.

  ViewCVS also treats symlinks like files/directories, so it can be
  used to navigate the symlink-based recipes.

  There are some relatively minor drawbacks to the symlink-based
  approach, which i describe below, mostly to document them for future
  reference.  I believe they're way outweighed by the benefits.

  Below is the list of drawbacks and benefits.  I'm going to test out
  the symlink-based scheme soon, and if it proves satisfactory (and
  barring objections), will be aiming to implement the switchover on
  friday, Aug 3.

Benefits:

 - As with modules, we can organize the repository in sensible ways
   for sharing packages, products, and so forth, in multiple
   applications.  We can transparently change actual repository file
   locations at will, moving the symlink targets to track the changes.

 - Unlike modules, indirected additions and deletions will be
   inherently tracked by CVS updates.

 - The composed elements will be visible to tools like ViewCVS as
   explicit elements, rather than invisible like they are now.

Disadvantages:

 - Changing these symlink-based repository structures currently
   requires repository host access.  We don't want to give that out,
   so that'll impose going through an administrative bottleneck for
   people wanting to make changes.

   We plan to provide a simple administrative (CVSROOT) file which
   dictates the crosslinking structure, and a mechanism which effects
   the changes when the file is checked in.  Until then, people
   without authority (almost everyone) will have to go through
   administrators to get such changes implemented.

 - Modules enable a bit more recipe reuse.  For instance, if you
   wanted two different versions of Zope, one with CMF included and
   one without, you could reuse a core Zope module in a ZopePlusCMF
   module.  We will be able to compensate, perhaps better, with
   distribution front-ends.