Re: Re-sync Cycle

[Greg A. Woods]

[ 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 <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>