Subject: Re: [boost] Review Queue Needs Attention
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-11-27 02:21:07
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 ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk