Subject: Re: [boost] [Git] Regression testing modular Boost
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-25 16:08:50
on Tue Dec 25 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
> On 12/17/2012 12:25 PM, Dave Abrahams wrote:
>> on Sun Dec 16 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>>> On Wed, Dec 12, 2012 at 9:49 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
>>>> On Tue, Dec 11, 2012 at 10:52 AM, Rene Rivera <grafikrobot_at_[hidden]>
>>> Hm.. That's barely a step :-\ ..And there's no need to branch. The tools
>>> already support multiple transport methods so we can just add another.
>>> Which brings me to one of the transport methods regression testing
>>> currently supports.. Downloading the current trunk/release as a ZIP
>>> archive. I was hoping to use the github facility that exists for
>>> downloading ZIPs of the repos. But unfortunately I couldn't make it
>>> attached the contents of the indirect references to the library
>> That's right, unfortunately. However, we can get the exact URLs of the
>> ZIP files from the GitHub API. I've recently done some scripting with
>> e.g. https://github.com/ryppl/ryppl/blob/develop/scripts/github2bitbucket.py#L40
>> In fact, I think someone has coded up what's needed to make a monolithic
>> zip here:
> 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.
>>> 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?
>>> Well.. In an ideal world it would be possible to have a fully integrated
>>> "monolithic" repo that the testers can just use as that is the simplest and
>>> likely most repliable path. But, alas, this hope of mine was essentially
>>> dismissed during the DVCS/git discussions.
>> This isn't about DVCS but about whether we're going to have real
> I don't know what you mean by "real modularity".
In this context I mean the ability to work on one part of a system
without being encumbered by the other parts.
-- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk