Re: [boost] [Git] Regression testing modular Boost

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-26 11:13:14

on Wed Dec 26 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:

> On 12/25/2012 3:08 PM, Dave Abrahams wrote:
>>
>> on Tue Dec 25 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>>
>>> After looking at both of those I see no point in using the github api
>>> (or additional structure data from sublime -- not totally sure where
>>> the submodule info comes from in this case though) for this as it
>>> provides no additional information than one can get from just parsing
>>> the ".gitmodules" file.
>>
>> I'm pretty sure that's not correct.  The .gitmodules file doesn't contain
>> information about which commit to check out for each submodule.
>
> Right it doesn't. But your ryppl code doesn't handle that either since
> it fetches the repos individually from the non-version-specific master
> branches (AFAICT). 

No, that's also incorrect.  Ryppl uses zeroinstall to fetch specific
versions of dependencies based on the output of a statisfiability
solver.

>>>>> Hence the complexity of supporting testing with ZIPs is now a
>>>>> magnitude larger as it means dealing with fetching more than a hundred
>>>>> individual repos :-(
>>>
>>> Which now seems the only choice. At the tester side I will have to get
>>> the boost-master archive. Then parse out the ".gitmodules" file. And
>>> get each subrepo archive individually. Which increases the likelihood
>>> of failure considerably.
>>
>> I'm not sure.  Isn't it true that shorter transfers are more likely to
>> succeed than longer ones?
>
> Perhaps, if one happens to have an not reliable internet
> connection. But I would expect testers to have reliable
> connections. But that's a minor unreliability.. The more likely
> problem is in code bugs in the testing script ;-)

OK, any new code comes with a risk of bugs, but seriously: this is not
the kind of monstrous increase in complexity that will be difficult to
code for, or to debug.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost