Re: git-svn should default to --repack
- From
Kevin Ballard <kevin@sb.org>
- Date
- Jan 19, 2008, 15:05 UTC
- Message-ID
- <BB932B28-08F3-4243-8E3B-ACC4527F947E@sb.org>
- In-Reply-To
- <20080119123557.GA30778@diana.vm.bytemark.co.uk>
Note: CC list pruned as, once again, my Mail client decided to send the original message as HTML and it got bounced from the list. Original CC list: kha@treskal.com, gitster@pobox.com
On Jan 19, 2008, at 7:35 AM, Karl Hasselström wrote:
Show 26 quoted lines
> On 2008-01-18 12:44:08 -0800, Junio C Hamano wrote: > >> Karl Hasselström <kha@treskal.com> writes: >> >>> I believe so too. And nowadays there's "git gc --auto", which was >>> made for occasions such as this, so it should be a breeze to >>> implement. The overhead might be low enough that it can be called >>> after _every_ imported revision. >> >> Careful. I made the same mistake and it had to be corrected with >> e0cd252eb0ba6453acd64762625b004aa4cc162b. >> >> "gc --auto" after every 1000 or so feels like a good default and I >> would agree that would be a real fix to a real usability bug. > > I think 1000 might be too high; considering that (at least in my > experience) it takes on the order of 250-500 ms to import a commit, > the gc --auto overhead of maybe 10 ms isn't so bad. > > A good compromise might be to run gc --auto after every 10-100 > commits, _and_ when the import is done. > > However, if gc --auto always takes a lot of time without accomplishing > anything in the presence of too many unreachable loose objects it > might not be a good idea to run it at all, since the use of git-svn > involves frequent rebasing.
I don't know much about how this works, so if git gc --auto might have a problem, it seems the simplest fix for now would be to default git- svn to having --repack=1000 on.
>> Patches? > > Just hot air and noise for now from my end. Sorry.
Same. I don't know Perl. Sorry.
-Kevin Ballard
-- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com