Re: [boost] trunk vs release (svn:externals)

Subject: Re: [boost] trunk vs release (svn:externals)
From: troy d. straszheim (troy_at_[hidden])
Date: 2009-05-25 08:05:36

Beman Dawes wrote:
> On Fri, May 22, 2009 at 11:38 AM, troy d. straszheim <troy_at_[hidden]>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