Re: git on small systems

[matthew sporleder <msporleder%gmail.com@localhost>]

On Tue, Jan 6, 2015 at 11:09 AM, matthew sporleder <msporleder%gmail.com@localhost> wrote:
> On Tue, Jan 6, 2015 at 11:08 AM, Justin Cormack
> <justin%specialbusservice.com@localhost> wrote:
>> On Tue, Jan 6, 2015 at 3:55 PM, matthew sporleder <msporleder%gmail.com@localhost> wrote:
>>> I did some testing over the last little bit for git on small systems.
>>> Please correct anything weird you see; I'm not a git master.
>>>
>>> I am testing on my VPC that looks like this:
>>>
>>> NetBSD vc136-15.vc.panix.com 6.0.2 NetBSD 6.0.2 (PANIX-VC) #0: Sun May
>>> 19 03:41:56 EDT 2013
>>> root%juggler.panix.com@localhost:/misc/obj/misc/devel/netbsd/6.0.2/src/sys/arch/amd64/compile/PANIX-VC
>>> amd64
>>
>> I am guessing that a 32 bit machine would use a noticeable amount
>> less, but the shallow clone looks excellent anyway. Since recent git
>> you can push from shallow clones which helps.
>>
>> Justin
>
> I wouldn't hold your breath, but if I get some time I'll try to get my
> rpi booting and see what I can accomplish.

So someone just gave me a login to an rpi (128 MB config)

the "shallow" clone worked without any trouble.  I'm actually pretty
excited to try this on pkgsrc.

Full clone, even over http, was killed by the UVM killer (not the
weird signal I was getting on my 512 box).

I am currently trying some more styles of clones on my 512 amd64 and
the rpi reconfigured for 256 but my predictions are this:

Even the smallest systems can easily track necessary branches for
security fixes, developing patches, etc using the shallow clone
methods described earlier.

A small-ish system like mine: 512MB + some swap + some git tuning can
get a full history clone.  I think this is probably the lowest
reasonable config for any kind of "normal" development (with the full
history).

1GB of memory is comfortable and probably doesn't require much tuning,
but I wouldn't mind seeing some testing.

NetBSD should offer git over http/https* because it appears to be more
memory-friendly.  I am also testing an ssh-based checkout (git:// was
not finishing).

* NetBSD does not ship with mozilla rootcerts so https requires some
extra stuff.


---

Anyway I hope this helped give some facts around the "small systems"
concerns of git.

I also think there are some server-side options that can help the
clients use less memory (smaller pack sizes or something like that) at
the expense of disk space.  I'd be interested to hear any ideas on
that for when we are testing netbsd.org hosted git mirrors.