NEXTSTEP 3.x's ProjectBuilder and InterfaceBuilder do not work well with CVS (Concurrent Versions System). Occasionally, InterfaceBuilder complains that it cannot save certain directories (e.g., nib's and rtfd's) containing a CVS administrative directory; saving a second time will force a successful save. But a successful save causes these CVS directories to be lost resulting in CVS complaining that it cannot check in these directories during a subsequent CVS commit. All CVS administrative directories are copied into the product when the "app", "debug", or "profile" targets are made. Although the
existence of these directories appears to cause no problems, it serves no purpose and increases the product size. cvs.postamble attempts to correct these problems.
In addition, CVS is big and complex making its use with NEXTSTEP projects even more difficult. So a goal of cvs.postamble is to simplify the use of CVS with NEXTSTEP and to integrate its use into ProjectBuilder.
Using cvs.postamble, all CVS commands can be run from ProjectBuilder using the various CVS targets. While this doesn't provide the degree of integration desirable (adding a file to the project doesn't result in it being automatically added to the CVS repository, importing a project into CVS doesn't parse the various PB.projects to determine what files to import, etc.), it does provide programmers with a mechanism to use CVS from within PB avoiding the need (in most cases) to go to the command line to run CVS operations. It also bundles several CVS operations into one target that attempts to "do the right thing" for the typical NEXTSTEP development project thus relieving the programmer from a little of CVS' excessive cognitive load requirements.
This version of cvs.postamble augments the functionality of the previous version, so the previous version should be replaced by this one.
Art Isbell Cubic Solutions
NeXT Registered Consultant NEXTSTEP software development and consulting
