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