So far, the main justification I've seen for build management in a
version control system is: if a project is (1) large, (2) rapidly
changing, and (3) not compartmentalized, then builds take too long, so
testing is sacrificed.
Here's why I don't find that argument compelling:
* The vast majority of projects are either not large, not rapidly
changing, or are easily compartmentalized.
* The particular problem can be solved independently of the version
control system. (And I believe it has, in the form of caching compiler
tools, though I can't find a pointer at the moment.)
* The cost of integrating this functionality deeply into a version
control system is that people have to (or may believe that they have to)
adopt your build tools as well as your version control system.
Version control systems have had more penetration than general
configuration management tools. The general problem is hard, and even
if you solve it, your potential users won't understand what your product
does and will be resistant to adopting all of the necessary changes in
work habits at once.
On Tue, 2002-05-21 at 02:54, Marc Girod wrote:
> - Derived objects are the general case of configuration items;
> versioned elements the exception.
> To see why, take the tree metaphor: the amount of leaves grows in r
> to the power of 2; the inside, to the power of 3.
Eh? An n-level complete binary tree has 2^n leaves and 2^n-1 interior
nodes. And I'm not sure why the tree metaphor is apt; it doesn't
correspond to the usual relationship of source and derived objects in a
project. (Though, in most projects I've seen, the number of derived
objects is roughly the same as the number of source objects, same as a
tree.)
(Maybe you were talking about a real-life tree? Then your statement is
true, but it still doesn't seem to have much to do with projects.)
> I believe nobody should care for yet another RCS. However smart.
Reductionist, unjustified, and manifestly contrary to reality.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 22 16:44:03 2002