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-26 18:57:04

Beman Dawes wrote:
> 
> 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?
> 

How about:  Branch A: the trunk @ HEAD.  Branch B: the trunk 100 commits 
ago, with fixes and patches sprinkled all over it, and a couple of 
proposed libraries added.  If there are no conflicts the merge happens 
in ~5 seconds or less.

> 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"?

(as above)

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

The externals:

libs/serialization
http://svn.boost.org/svn/boost/projects/serialization/trunk

libs/flyweight
http://svn.boost.org/svn/boost/projects/flyweight/trunk

Of course I've just argued that you don't want to do this, but the 
reason you would is to be able to create subdistributions of boost
and version components independently of one another.

This doesn't take care of constructing your single include/ directory.

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

Well there is the approach that Qt has been using for many years, which 
Juergen pointed out.  I coded up a prototype, see mails in this thread 
with 'qtsync' in the subject.

-troy