What do you say? Is Software Configuration Management the build system's job? Or is it a shared responsibility between the SCM/VC system and the build system?
I don't really agree with anybody on this thread...
The problem is probably in the question, and more precisely in the 'is' predicate.
SCM is about management, and shouldn't make sense unless it would be itself manageable. Thus it has to take responsibility for its presentation of reality: it cannot accept arguments of authority. Thus nothing is unless we want it and know why.
The special kind of sophisticated SCM I'd wish to achieve/evolve (trying to avoid the word 'build'), based on concepts taken from clearmake, would reverse the terms of the assertion: SCM is a by-product of Build Management.
I have already attempted to develop this idea, e.g. in: DO Management, or in: DO as CI, but here is a new bit of argument: identification makes only sense for stable artifacts. Unless the SCM/build tool provides a way to promote, save, and share derived objects, the only stable artifacts are (hand-produced, and thus slowly changing) 'sources'. But as soon as the life-time of DOs gets extended, it becomes possible to base the whole identification on them, and this makes much more sense than the traditional state-of-things.
This is because DOs have more intrinsic value, because they have a structure (based on dependency graphs), and because they may typically be run (they don't need to be painstakingly interpreted).
Marc
No comments:
Post a Comment