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

Subject: Re: [boost] trunk vs release (svn:externals)
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-05-26 06:58:53

On Mon, May 25, 2009 at 8:05 AM, troy d. straszheim <troy_at_[hidden]>wrote:

> 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.)

Didn't svnmerge become obsolete when Subversion added merge tracking?

> 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.

I find "bona fide merges" and similar terms somewhat offensive. People are
always claiming this or that source control system doesn't do "bona fide
merges". Well, even the really crappy systems handle at least some merge
scenarios without problems. Is there any SCS that handles all possible merge
scenarios? I doubt it.

What is the specific merge scenario that you are concerned about? Does the
concern still apply to SVN 1.5 and later?

Note that under the svn:externals scheme, one not only can't do a wide
> merge,

Could you explain what you mean by "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

I'm trying to understand why this would be necessary. For a given library,
what directory has the svn:externals property? What does the svn:externals
property entry look like for a given library? Why do the externals have to
be changed? Is the root problem that the svn:externals property has to be
attached to a directory above the library's boost-root/libs/libname page
because svn:externals properties targets don't support ".." in their paths?

What might an optimal solution to keeping headers in their library tree look
like that didn't use svn:externals? Perhaps something like this:

* For users (i.e. anyone needing read-only access), a post-checkout step
that moved the headers from their library tree to boost-root/boost.

* For developers (i.e. anyone needing read/write access), a post-checkout
step that created hard links in boost-root/boost.

Something to think about if svn:externals can't be made to work.

--Beman