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.