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 16:46:13

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

> > 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. At which point I could just do #1 above
each time. Which is certainly disk space efficient, but obviously not
bandwidth efficient. And it's likely going to be that I just start with
doing #1 only. Until I can figure out how to do the rest.

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