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

Subject: Re: [boost] trunk vs release (svn:externals)
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-26 11:10:55

Beman Dawes wrote:

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

I don't think the server was upgraded.

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

As I've pointed to on IRC already, merge tracking in SVN 1.5 is in some aspects
more powerful than in git. So maybe it's best, indeed, to stop mixing version
control system discussion with an otherwise tricky topic.

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

>From IRC discussion, it seems that Troy and I had different use of svn:externals
in mind. I assumed that 

        trunk/boost

has svn:externals for each headers directory, e.g.

        filesystem ../libs/filesystem/headers

Therefore upon checkout, you get a complete copy of all headers in 'boost' dir.
This arrangement does not create any problems for branching or merging whatsoever.

What Troy had in mind (according to my understanding, which may be faulty), is that
svn:externals are used on 

        trunk/libs

and pull libraries from some other location. This will indeed create additional
inconvenience for merges, but it's not clear why this arrangement is desired.

- Volodya