On Jan 30, 2007, at 9:44 AM, kelvin goodson wrote:
Jeremy,
thanks for your reply. A key time when this has become an issue
for me is
when applying patches. My general process has been to ensure I have a
complete clean svn extraction, build it to see if there are any
current
issues in the trunk, inspect and apply the patch and build it
again. If
there are deltas in the error sets (hopefully the initial build's
error set
was empty) then there's an issue with the patch.
Shouldn't this be done using unit and integration tests, and not
against the entire trunk? For example, particular extensions may
reference different versions of SDO. I would imagine we need to be
able to accommodate a patch introducing API changes for a later
version than one referenced by a particular extension.
This has meant in the past
often even small patches still take an hour or so to apply.
Isn't that a problem in itself?
Now that the
trunk has significantly less chance of being stable this has become
unworkable.
It has been my experience that the previous build structure was
unworkable since it did not allow extensions to evolve independently.
Solving this issue by modularizing unfortunately means an upstream
module cannot make assumptions about downstream modules, for example,
that they reference HEAD or a particular version and will compile
against it. The best solutions I have seen in the past to this
problem is extensive unit and integration tests in the upstream
module. If these are done right, it should be trivial to apply small
patches since they can be verified by the current build run.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
