[ On Wednesday, December 31, 2003 at 08:00:23 (-0500), Brice Oliver wrote: ] > Subject: Re-sync Cycle > > A developer is working on project A, which creates new code that calls a > common function (the function is not included in project A). This function > is changed as part of another project, project B. Project B's changes are > committed to the repository before Project A. Unfortunately, the function > changes in Project B would cause Project A's testing to fail. However, > since this function is not in Project A's list, the developer would miss it > in his testing / commit to CVS cycle. To handle this situation, should a > complete re-synch be done before every test/commit cycle? Should a watch be > placed on every function that a project uses?
This is really just a very generic old-fashioned software configuration and/or software hygiene management problem (and would be better discussed in nntp://comp.software.config-mgmt/ :-) Basically what you've described is a total lack of configuration and release management for your internal modules and the result is the typical chaos many projects face when they try to track the bleeding edge of new development in all the internal components they use. To avoid this chaos / bleeding-edge syndrome all shared code should be isolated in its own modules and be separately managed (tested, released, etc. just like an independent project) as required. It should have a sufficiently well defined API (and perhaps ABI if it's in a compiled language) such that its users will know what to expect from it, though so long as all changes that might affect the API (and or ABI) of the shared code are isolated into separate releases of their modules then the projects that use the shared code modules can selectively avoid being affected by incompatible changes in the shared code (at the expense of course of having to live with older and potentially buggy releases of those shared modules). I.e. the projects which use such shared code modules should be built with a mechanism that allows them to track given releases or branches of the shared code such that changes to the API (or ABI) of the shared code during its ongoing separate mainatenance doesn't affect the project directly. Typically this might involve installing the product libraries and headers of the shared modules in "versioned" directories such that the makefiles for each project using those modules can carefully select specific releases of the shared modules. None of this involves CVS directly. :-) -- Greg A. Woods +1 416 218-0098 VE3TCP RoboHack <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
