Tim Blechmann wrote:
>> (And a state not damned with faint praise like 'unstable' - which is perhaps >> better described as 'likely_to_be_improved' rather than actively 'not stable').
The apache incubator might be a more appropriate inspiration than Debian unstable.
the current sandbox layout has the disadvantage, that single projects are present as sandbox/mylib, which do not run or compile on their own, but require a full set of the boost headers. in order to try out one sandbox library, you need to get the boost checkout/tarball and copy it to sandbox/mylib or vice versa ...
Just to clarify -- what is wrong with starting with checkout of 'main' Boost tree, and then doing 2 "svn co" per any sandbox library you want to try?
not sure, whether i understand it correctly. if i check out trunk and sandbox/mylib to myboost/ ... then myboost would contain 2 independent svn checkouts ... does `svn diff' show the diff with trunk or with sandbox/mylib then?
"svn diff" without arguments will show difference in 'main boost' "svn diff boost/mylib libs/mylib" will show the difference for the specified library -- but this is probably obvious.
Is this a problem and what alternatives do you suggest?
well, both checkouts wouldn't be synchronized ... a distributed version control system would fit for this use case way better ... i don't want to start a scm flamewar, but for me svn appears to be very limited compared to tools like git ...
We could probably indeed start a nice flamewar on version control, but before we go that route, I wanted to double check. Is this inconvenience of combining sanbbox libraries with main release the primary issue with the current organization of sandbox? Or there are other issues? Could you list them? Because if it's the only issue, we're doing pretty well ;-) - Volodya