Beman Dawes wrote:
On Fri, May 22, 2009 at 11:38 AM, troy d. straszheim <troy@resophonic.com>wrote:
I said I was "out of ideas", but that was a little disingenuous. This is certainly one of many possible implementations, but I urge caution here. We've been using svn:externals for subproject management for a while, against the conventional wisdom. It makes merging even harder, can turn a large difficult-to-merge project into an impossible to merge project. You can end up needing to write tools to wrangle your externals. It won't be too hard to make a sample implementation to show how it works, I think this will help clarify things.
Is this a project that does project-wide merges? I can see how that might be a problem.
Boost developers and release managers, OTOH, don't ever do project wide merges. Instead, everything happens on a library by library basis. I would expect merging a single library would be easier if its header files lived entirely within the library's boost-root/libs/libname tree.
Having libraries organized with nearby headers may be a better organization scheme and make some operations easier: agreed, we'll try it out. I'll maintain that whether or not to put these perhaps-better-organized directories on the ends of svn:externals is a different issue with long term consequences. Right now boost developers and release managers do single project switches; (modulo those who go to the trouble of using svnmerge.) Naturally that isn't an argument _for_ locking in to a path that excludes the possibility of bonafide merges, assuming there is some alternative. This would be a bit like (hypothetical) deciding on a path that somehow restricted us to using fixed size containers, just because we're getting by without them right now. Note that under the svn:externals scheme, one not only can't do a wide merge, one can't even wide-branch easily. You must: - branch the toplevel project (a commit) - foreach project that you want to modify - branch it (a commit) - change your externals and commit What should be an instantaneous local operation becomes a tedious operation involving multiple commits. Consider creating the c++0x branch in this context. Take also boost 'power users': these may be maintaining side projects, proposed libraries, and large patchsets. For instance, Joel Falcou and I are collaborating on an effort that requires - trunk (lots of spirit and proto) - our own patches to trunk - process - extension - other proposed libraries - our own stuff We'll be reporting bugs back to Hartmut and Joel, provoking and tracking changes on the trunk, reapplying various local patches that we're maintaining. The necessary primitive operation here is a merge: a real actual merge of the latest changes from trunk into our development branch. externals-wrangling is a big hindrance here. -t