dist-git status

[Carl Worth]

On Wed, 15 Nov 2006 17:19:39 -0500, Bill Nottingham wrote:
> Jim Meyering (meyering at redhat.com) said:
> > The only other explanation I can come up with is that
> > some packages have consistently huge commits.  For such
> > packages, 1024 may be too large.
>
> This is not something that should be tweaked on a per-package basis,
> or something the SCM admin should really know (or care!) about.

First, this is really only an issue for the importer, not anything to
do with git itself. And it should be easy enough to fix the importer
to trigger the repack based on the total size of the unpacked objects
rather than the number.

As for packing repositories in actual use, (as opposed to during the
import process), the git admin should learn that a repack should be
done just after backing things up, and the existing backup schedule
can set that schedule.

When I first encountered git I thought the manual repack was really
annoying, but as I learned more about it, it's really just what an
admin wants who really cares about the data being stored. Before
repacking, any single-file corruption (for whatever disastrous reason)
can affect only a single object in git. The packing changes that, so
it's nice that the admin can postpone that until just after backing up
the loose objects. Similarly, in normal operation, files in the object
store are only created, never modified or deleted. The prune that
often follows the repack changes that, so again, it's useful to be
able to time that right after the backup.

So all the admin has to learn is to just do:

	git repack -a -d && git prune-packed

just after doing backups or so. (There are other impacts of packing if
the repository is to be made available over http: transport in
addition to git: transport so it might be desired to repack less
frequently if that is important).

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20061115/95a957fe/attachment.sig>