Re: [boost] [git] Bumping git version requirement to 1.7.10

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 
>>>> development
>>>> machines.
>>>
>>> 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 
>> risk
>> 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 
>> governance
>> 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.)

Peter