Hi, Thanks for the great suggestions. It turns out that running the command: git repack -a -f -d on the newly converted git repository seemed to fix my immediate crashing-while-cloning problem. I was able to clone via ssh from the older Ubuntu machine with 1G of RAM using git version 1.5.4.3 (the packaged version in Hardy Heron). I also downloaded what seems to be the latest of the 1.5 series, 1.5.6.5, installed that from source, and successfully tested that out. I'll try using that to avoid some of the memory problems of the previous versions. As I'm still comparatively a complete newbie when it comes to git, I don't have a clue yet as to what's in the 1.6 codebase but hopefully I'll be able to determine which version I want to work with soon. Thanks again for the help! I really appreciate it. -Paul Nicolas Pitre wrote: > On Wed, 12 Nov 2008, Paul E. Rybski wrote: > >> Hi, >> I've recently started evaluating git for use on one of my projects. I >> used git-svn to convert a fairly large subversion repository and one of >> its branches into two separate git repositories following the >> instructions found here: >> >> http://www.simplisticcomplexity.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/ >> >> From that, I created a 1.5G repository from the trunk of the subversion >> repo and a 1.1G repository from one of the branches. I then tried to >> clone the repositories from one machine to another via ssh and the >> smaller 1.1G repository of the subversion branch (with 1932 commits) >> came over just fine but the larger 1.5G repository of the subversion >> trunk (5865 commits) died with the following error: >> >> remote: Counting objects: 48415, done. >> remote: warning: suboptimal pack - out of memory >> error: git-upload-pack: git-pack-objects died with error. >> fatal: git-upload-pack: aborting due to possible repository corruption >> on the remote side. >> remote: aborting due to possible repository corruption on the remote side. >> fatal: early EOF >> fatal: index-pack failed >> >> Is this simply because the git repository is too large for the machine >> that's trying to send it over ssh? > > Possibly. > >> Is there a way to restrict the memory usage of git or do I need to get >> more RAM or somehow not import the full subversion history of my >> original trunk? > > It is possible that the inport from svn didn't produce a fully packed > repository. Try a "git repack -a -f -d" on the server machine. If you > get the same out-of-memory problem then ideally you should copy the > whole directory to a bigger machine and run 'git repack -a -f -d" there. > Then you may copy it back to the small machine and subsequent clone > requests should be just fine. > > You could also investigate the pack.windowMemory configuration variable > on the server side. If you have lots of big files then setting this to > 64m for example may help. > >> I'm using Ubuntu 8.04.1 on both machines and using the Ubuntu packages >> of git version 1.5.4.3. > > There was a bug in versions prior to v1.5.6.4 affecting memory usage. > Upgrading to this version or later on the server machine might help too. > >> The machine holding the repository is a 5-year >> old AthlonXP 3200 with 1G RAM and 32-bit Ubuntu. The machine I'm >> cloning the repository on is a more recent Intel Dual Core Quad Q6600 >> with 4GRAM and 64-bit Ubuntu. >> >> Any advice would be greatly appreciated. >> >> Thanks! >> >> -Paul -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
