Re: svn to git, N-squared?
- From
Jon Smirl <jonsmirl@gmail.com>
- Date
- Jun 12, 2006, 03:39 UTC
- Message-ID
- <9e4733910606112039p7aff60c7w7a074d0e35c7b0f@mail.gmail.com>
- In-Reply-To
- <Pine.LNX.4.64.0606112028010.5498@g5.osdl.org>
On 6/11/06, Linus Torvalds <torvalds@osdl.org> wrote:
Show 22 quoted lines
> > > On Sun, 11 Jun 2006, Jon Smirl wrote: > > > > I have Mozilla CVS in a SVN repository. I've been using git-svnimport > > to import it. This time I am letting it run to completion; but the > > import has been running for four days now and it is only up to 2004. > > The import task is stable at 570MB and it is using about 50% of my > > CPU. It is constantly spawning off git write-tree, read-tree, > > hash-object, update-index. It is not doing excessive disk activity. > > This sounds like _exactly_ what happens if you don't repack occasionally. > Expecially if you are using a filesystem without hashed filename lookup, > but it's true to some degree even with that - the filesystem tends to end > up spending tons of time in kernel space, trying to find a place to put > new objects. > > I don't think git-svnimport has the repack logic in it, so that would be > it. > > You can probably stop it with ^Z, do a "git repack -a -d", and then let it > continue.
I have it stopped and I am running the repack. There are 1.27M files in my .git directory
I ordered 2GB more RAM which should be here Tuesday.
Show 8 quoted lines
> (The only reason for stopping it is actually to let "git repack" remove > most of the object directories - many filesystems, including ext3, don't > even speed up all that much if the directories are emptied after they've > grown big, and it's much better if the object directories get totally > removed and re-created) > > Linus >
-- Jon Smirl jonsmirl@gmail.com