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?
>>>> 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
> 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:
> 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
-- 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk