On Mon, Dec 30, 2013 at 1:26 PM, Vladimir Prus wrote:

On 30.12.2013 23:22, Eric Niebler wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 12/30/2013 06:47 AM, Beman Dawes wrote:

...

The regression scripts are using the clone --single-branch option, which became available at git 1.7.10, so we are planning to bump the version requirement.

Unless I'm mistaken, the most recent Ubuntu LTS release is still on 1.7.9.5. I think this change would inconvenience a significant segment of users.

And it seems one can accomplish the same effect with earlier versions:

http://stackoverflow.com/questions/1911109/git-clone-a- specific-branch

Hm.. It's not clear from the docs that they are equivalent. "-b" checks out the given branch. While "--single-branch" clones only the data for the branch. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

On Tue, Dec 31, 2013 at 2:15 AM, Vladimir Prus wrote:

On 30.12.2013 23:34, Rene Rivera wrote:

...

On Mon, Dec 30, 2013 at 1:26 PM, Vladimir Prus wrote:

On 30.12.2013 23:22, Eric Niebler wrote:

...

-----BEGIN PGP SIGNED MESSAGE-----

...

Hash: SHA1

On 12/30/2013 06:47 AM, Beman Dawes wrote:

The regression scripts are using the clone --single-branch option,

...

which became available at git 1.7.10, so we are planning to bump the version requirement.

Unless I'm mistaken, the most recent Ubuntu LTS release is still on 1.7.9.5. I think this change would inconvenience a significant segment of users.

And it seems one can accomplish the same effect with earlier versions:

http://stackoverflow.com/questions/1911109/git-clone-a- specific-branch

Hm.. It's not clear from the docs that they are equivalent. "-b" checks

out the given branch. While "--single-branch" clones only the data for the branch.

I have referring to this:

git init git remote add -t refspec remotename host:/dir.git git fetch

Here's a specific example:

$ git init . $ git remote add --no-tags -t develop origin git@github.com: boostorg/build.git $ git fetch remote: Compressing objects: 100% (13708/13708), done. remote: Total 52255 (delta 37252), reused 52250 (delta 37248) Receiving objects: 100% (52255/52255), 27.04 MiB | 2.44 MiB/s, done. Resolving deltas: 100% (37252/37252), done.

On the other hand, it does not reduce much of download size, compares to full clone:

remote: Counting objects: 55789, done. remote: Compressing objects: 100% (15291/15291), done. remote: Total 55789 (delta 38985), reused 55742 (delta 38939) Receiving objects: 100% (55789/55789), 28.62 MiB | 691 KiB/s, done. Resolving deltas: 100% (38985/38985), done.

Presumably because there are merge commits on 'develop' having commits from both master and develop as parent.

Maybe, if you really want to reduce download speed, you need --depth option? Like so:

$ git init . $ git remote add --no-tags -t develop origin git@github.com: boostorg/build.git $ git fetch --depth=1 remote: Counting objects: 967, done. remote: Compressing objects: 100% (882/882), done. remote: Total 967 (delta 72), reused 806 (delta 57) Receiving objects: 100% (967/967), 2.10 MiB | 567 KiB/s, done. Resolving deltas: 100% (72/72), done.

Note that using just --depth=1 without --no-tags and -t to remote add fetches 7MiB, so the above is probably the smallest you can get.

Awesome.. I have that working after adding some missing commands: $ git checkout develop $ git submodule update --init --merge Although I suspect that this doesn't reduce overall bandwidth much as most of the cost is in cloning the submodules. And I think it clones them completely regardless. I'll check in the changes shortly. And a change that fixes the key problem with Windows testing (it wasn't doing a chdir out of the boost_root and hence it kept the dir locked). -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

FYI, I noticed in the git release notes that releases 1.8.3-5 have changes to the way git-submodule works, so we may need to either bump even further if the modified behavior is desired or set a *maxiumum* version of git to use until we've decided how to incorporate the new functionality into our processes/documentation. Michael

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. Peter

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