On Nov 8, 2006, at 11:04 AM, Joe Bohn wrote:
Kevan Miller wrote:
2) Develop in a sparse source tree. The source tree only contains
the new code that is being developed. The hope is that this
reduces the overhead of merging changes. However, it will also
complicate the build process -- it seems that Joe has been having
problems building using this technique.
It isn't just a problem of building via a sparse tree (though it
does make the build process more complex). I don't think it is
feasible to manage a sparse tree for when "common components" that
already live in trunk need to be updated as a result of some
changes for a component in the sparse tree ... see my earlier
response to David. If you really want to try the sparse tree
approach then I think you need to move *all* configs out of trunk
and into the sparse tree which will be disruptive to trunk (and
hence 1.2).
Well, I'm assuming that "building" means building new jars, new/
modified configs, and new/modified assemblies. You'd have merge
overhead for any overlapping components. I don't really understand
why you'd move configs out of trunk... However, if a sparse tree
doesn't work, then it doesn't work. I certainly haven't spent any
time looking at it...
--kevan
