
On Sat, Dec 29, 2012 at 2:15 PM, Dave Abrahams <dave@boostpro.com> 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@boostpro.com> 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?
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