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

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-12-29 17:31:09

On Sat, Dec 29, 2012 at 4:04 PM, Dave Abrahams <dave_at_[hidden]> wrote:

>
> 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?
>

Depends on your POV. It's pure in that it doesn't depend on the git sources
or binaries. But <https://github.com/jelmer/dulwich/tree/master/dulwich>
certainly has C sources to compile.

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

True.. But it's only an ideal. I'm not going go to extremes to achieve the
minimum. But certainly trying to conserve space can be helpful. Since the
whole of Boost can be large. And I certainly hope we can find ways to
reduce the binary footprint also moving forward.

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

I suspect as much also. But perhaps someone who knows the innards of git
can give a definite answer.

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