[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: git on small systems
On Tue, Jan 6, 2015 at 8:22 PM, matthew sporleder <msporleder%gmail.com@localhost> wrote:
> 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
>>> 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.
>> 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
> 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.
for the record: the ssh clone also failed on my 512 system.
I would suggest we do a weekly git bundle or git archive to handle
this clone overhead issue, which is similar to offering rsync/sup/etc
Main Index |
Thread Index |