<br><br>On Wednesday, September 12, 2012, Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br>> On Tue, 2012-09-11 at 20:44 -0600, Gary Thomas wrote:<br>
>> On 2012-09-05 22:35, Khem Raj wrote:<br>>> > svn tar balls are 96M as compared to 1.3G git tars<br>>> > its unnessary to suck in that much of data.<br>>> ><br>>> > Fixes [YOCTO #2908]<br>
>> ><br>>> > Signed-off-by: Khem Raj <<a href="mailto:raj.khem@gmail.com">raj.khem@gmail.com</a>><br>>><br>>> What about this patch? Carrying around a 1.7GB (Sorry, Khem, that's the size of my tar ball!)<br>
>> is a bit much, especially when that's what I send to my customers...<br>><br>> I've been hoping to find some time to do something with the fetcher to<br>> try and fix this corner we've ended up pinned into.<br>
><br>> Ideally I'd like to see both gcc and eglibc using git, we have git in<br>> ASSUME_PROVIDED and everything is optimal.<br>><br>> I'm not going to reach the release point without doing something about<br>
> this but I would like to stick with git if we can possibly help it.<br>><br>> Having to build subversion-native for critical path components is a<br>> major pain and performance issue.<br>><br><br>I agree but then 1.7 GB is noticeably huge too and it will only become larger in future so I don't think fetching from git will be a good solution for gcc ever. I was thinking we could Generate tar ball ourselves and put it on yp mirror. And in future use up stream release tar balls.<br>
> Cheers,<br>><br>> Richard<br>><br>><br>> _______________________________________________<br>> Openembedded-core mailing list<br>> <a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.openembedded.org</a><br>
> <a href="http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core">http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core</a><br>>