Subject: Re: [boost] SVN, branches and sandbox (Was: Review Queue Needs Attention)o
From: Tim Blechmann (tim_at_[hidden])
Date: 2009-12-11 07:15:57
>>>> 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
>>>> 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 ...
>>> 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' ...
but, well, i don't want to start a flame war ... and since i don't have
to use svn for my development, i don't care ... i am a happy user of the
git repositories of boost (svn mirror), boost.atomic and boost.lockfree,
though ... using svn for this would be possible, but quite a pain (i
guess you can read `git' as `professional distributed version control
system')
tim
-- tim_at_[hidden] http://tim.klingt.org The first question I ask myself when something doesn't seem to be beautiful is why do I think it's not beautiful. And very shortly you discover that there is no reason. John Cage.