Re: [boost] SVN, branches and sandbox (Was: Review Queue Needs Attention)o

Subject: Re: [boost] SVN, branches and sandbox (Was: Review Queue Needs Attention)o
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-12-11 07:33:08

Tim Blechmann wrote:

>>>>> consider the following use case:
>>>>> boost (upstream) contains boost/memory_order.hpp
>>>>> my_lib uses boost/memory_order.hpp
>>>>>
>>>>> boost (upstream) doesn't define memory_order_consume, my_lib requires
>>>>> memory_order_consume to be defined in boost/memory_order.hpp
>>>>
>>>> And -- what version of what does contain those function there?
>>>
>>> boost-1.41 doesn't contain memory_order_consume, in my use case,
>>> boost.atomic does need memory_order_consume. so the boost.atomic
>>> repository should provide an updated boost/memory_order.hpp, which is
>>> not possible when using 2 svn repositories, is it?
>> 
>> Why do you need 2 svn repositories in the first place?
> 
> your idea:
> http://article.gmane.org/gmane.comp.lib.boost.devel/197000

That was before you told you have cross-dependencies between sandbox libraries.
If there is, I would imagine the branches have to be created in the same
repository where trunk lives.

>>>>> so both repository checkout clash ... using one merged git repository,
>>>>> this is no issue (possibly the same with mercurial or bazaar)
>>>>
>>>> Probably the same using SVN. If somebody has a branch called
>>>> 'memory_order_with_cool_functions', and you have branch called 'tim', then it's not clear to me
>>>> why you cannot merge relevant commits from 'memory_order_with_cool_functions' to 'tim'.
>>>
>>> - upcoming boost libraries using the sandbox layout do not provide the
>>> boost upstream code
>>> - svn doesn't provide local branches, does it?
>>> - builing `out of place' is undocumented/ugly/hard to configure
>> 
>> Hmm, that does not actually answer my question. If you have a library that
>> cannot work with trunk or release, then you naturally need to put together
>> a branch of Boost that your library can work this. And if you do that, it
>> makes sense to include that library in the tree as well. So, that would be:
>> 
>> 1: somebody else
>> 
>> svn copy ^/trunk ^/branches/improved_memory_order
>>     svn switch ^/branches/improved_memory_order
>>     <hack-hack>
>>     svn commit -m "Very good"
>> 
>> 2. You, later
>> 
>>     svn copy ^/branches/improved_memory_order ^/branches/atomic
>>     svn switch ^/branches/atomic
>>     svn add boost/atomic libs/atomic
>>     <hack some more>
>>     svn commit -m "Initial version"
>>  
>> Is there any reason why this would not work? Note that it means you no longer
>> develop your library using the same layout as most sandbox libraries, but it's
>> a consequence of the fact that you depend on a version of code not in trunk.
> 
> nothing wrong with this, if you have a sandbox svn account ...

In practice, getting a SVN account takes a day at most.

>>>> Is this a real use case? If so, maybe you can point me at URLs and we'll check
>>>> in detail?
>>>
>>> you can find the boost.atomic code in helge's git repository:
>>> http://git.chaoticmind.net/cgi-bin/cgit.cgi/boost.atomic/
>> 
>> Oh. Obviously, if your code is in git, then you cannot use "svn merge" with it ;-)
> 
> the increased productivity with using git does well outperform the lost
> productivity of not being able to use `svn merge' ...

So, it appears we've arrived at the following list of issue with the
current official arrangement.
- sandbox is physically different SVN repository,
- handling cross-dependencies between sandbox libraries require full
branches, as opposed to just boost/X + libs/X layout
- getting SVN access is hard (in your opinion)
- git makes you, personally, more productive

Is that correct understanding?

- Volodya