Re: Move to git is imminent - awaiting Stefan's approval

[Bob Proulx <bob@proulx.com>]

Bob Proulx wrote:
> It sounds like I should schedule a full agressive repack once.  Once
> being the operative word.
> 
>   git repack -a -d -f --window=250 --depth=250

This has been done and the repository is now down to 285M.  I set the
number of pack.threads=2 and it ran for 104 minutes to completion.

(I had experimented letting it use all available 7-cores but that ran
94 minutes and ran out of memory at the 3G 32-bit limit.  The progress
indicator took 15 minutes to get to 90% and then spent the next 80
minutes getting no further than 92%.)

> > Another option is to touch a <pack>.keep file for the largest pack so
> > that it is never touched again.  New objects will then be added to a
> > separate pack even after git gc.  If that large pack is already well
> > packed this should save some processing time.
> 
> That seems like a useful additional tweak for a large stage such as
> this.  If nothing else it will help out the backup since that file
> won't be changing on a routine basis and will remain static for the
> purposes of backup transfer.  This could be applied to several of the
> large repositories.
> 
> It seems that on the client side after a new clone that this tweak is
> not propagated.  It seems that if there are multiple packs on the
> server side that they are combined into a single pack file.  But
> without being repacked.  Therefore downstream clients that wish this
> would need to do it manually after a clone.

I also touched the .keep file for the resulting pack file so that it
would remain static.

I checked out a local clone and the size was 329M.

Bob

P.S. I saw the other discussion thread talking about possibly redoing
the repository.  If that happens let me know and I will repack just as
above again.