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

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-29 17:04:00

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

> On Sat, Dec 29, 2012 at 2:15 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>
>>
>> on Fri Dec 28 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>>
>> > Just getting back to this as the drive on my mac is now repaired.. In a
>> > totally empty state :-(
>> >
>> > On Wed, Dec 26, 2012 at 10:14 AM, Dave Abrahams <dave_at_[hidden]>
>> wrote:
>> >
>> >>
>> >> on Wed Dec 26 2012, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
>> >> > OK.. What's is the not manual way to do this without having git?
>> >>
>> >> http://www.samba.org/~jelmer/dulwich/
>> >
>> > OK.. That helps somewhat. It makes it possible to just write one piece of
>> > code for all testers (since we require python and we can add installing
>> > dulwich to that).
>>
>> It's even possible to write a script that creates a virtualenv and
>> installs dulwich there on demand, so testers don't have to do it
>> manually.
>>
>
> Except that dulwich requires compiling a C module. 

It does?  

   "Dulwich is a pure-Python implementation of the Git file formats and protocols."

Is http://www.samba.org/~jelmer/dulwich/ lying?

> So virtual installing wouldn't work.. Right?

>> > My goal is to have the equivalent of:
>> >
>> >     git clone -b <branch> --depth 1 --recursive
>> > https://github.com/boost-lib/boost.git <some-test-dir>
>> >
>> > The first time, but with the shallow depth also applied recursively
>> > (something which seems to me to be a bug in git). And subsequent times
>> > doing:
>> >
>> >     git pull --recurse-submodules https://github.com/boost-lib/boost.git
>> > <branch>
>> >
>> > Or at least that what I understand will give me only the current
>> > revision/s the first time. And then get only the subsequent updates
>> > correctly applied.  Help in verifying that those would be the
>> > correct base git commands to emulate is appreciated. For those that
>> > will question why I'm going to the trouble.. One of the goals of
>> > the testing scripts is to minimize disk space *and* network
>> > bandwidth. 

The disk space concern seems a bit misplaced given the size of the
generated binaries.  I mean, keep it from exploding, of course, but
*minimizing* it seems like overkill.

>> > Hence the convoluted fetch as minimal info as possible and store as
>> > minimal info as possible. Which brings a question..
>> >
>> >     Is there a way to have the local repo only store the current HEAD
>> > revision files (i.e. minimize the contents of the .git dir)?
>>
>> I think that's the shallow clone technique you're using above (--depth
>> 1).  Do you have something else in mind?
>
> I was asking both is that what #1 does initially and is there a way to make
> #2 not keep old history. And obviously how would I go about doing it with
> dulwich.

I *think* the answer to the first question is that there is no way to
make #2 not keep old history.

>> > And also..
>> >
>> >     Is it possible to only store the specific branch revisions in the git
>> > repo dir?
>>
>> I don't know, but at this point you might consider whether it would be
>> more efficient to simply get the information about submodule refs and
>> then download/unpack all the appropriate .zip files
>
> But I know doing the zips would be less efficient as I would have to
> download them all, all the time. 

Only if the refs change.

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