Subject: Re: [boost] [git] Bumping git version requirement to 1.7.10
From: Peter A. Bigot (pab_at_[hidden])
Date: 2013-12-31 08:21:27
On 12/31/2013 06:50 AM, Vladimir Prus wrote:
> On 31.12.2013 16:43, Peter A. Bigot wrote:
>> On 12/31/2013 02:17 AM, Vladimir Prus wrote:
>>> On 30.12.2013 23:43, Peter A. Bigot wrote:
>>>> IOW, this requirement may not actually impact many people,
>>>> especially if testing is normally done in cloud VMs rather than on
>>> Why do you assume that testing happens on cloud VMs?
>> I don't. I thought I recently saw some discussion of how to set up a
>> VM to support the new scripts, so I tried to address that.
>> Updating a package on a development machine beyond what the vendor
>> provides introduces risk. What I meant to convey was, git version
>> requirements of a specific test-framework script need not affect
>> people who do not run that script, and if that's most people then the
>> is limited. Having a set of standard VM configurations for testing
>> (on the cloud or locally) also mitigates the risk.
>> In this context (a git dependency in regression.py), I am also
>> specifically referring to super-project regression testing, a subset of
>> testing that is primarily important for integration verification.
>> Continuous integration should be a Boost process goal given its
>> model, and CI is rarely done on a developer's desktop. I would
>> expect Boost to move toward doing regression testing on VMs, perhaps
>> on a
>> hosted service like travis-ci.org which is free for open source
>> projects and has decent github integration.
> I think there's a difference between a model we'd use given infinite
> resources, and the practical situation - where getting releases
> tested and created is complicated. Having to build and install
> extra-fresh version of git just makes it more complicated.
As I understand it, the new requirement derives from a desire to speed
up the time it takes to get the test workspace. This is done by cloning
only the tested branch of every submodule from the master repositories
on github, which requires the new switch so unwanted revisions aren't
transferred. This itself is an extremely heavyweight operation, and
reworking the regression script so it first updates a local set of
repositories then clones from that would eliminate both the need for the
git upgrade and the unnecessary network transfers. In fact, the only
argument I imagine I saw for not doing that in the first place was a
desire to run in a VM that was reset to a state where it didn't have the
repositories already available.
(On systems that support hard links, cloning a repository on the same
file system does not replicate the metadata and is a very cheap operation.)