Re: [PATCH] Make repack less likely to corrupt repository

From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Feb 10, 2009, 16:57 UTC
Message-ID: <200902101758.00062.robin.rosenberg@dewire.com>
In-Reply-To: <7viqninuzv.fsf@gitster.siamese.dyndns.org>

tisdag 10 februari 2009 16:59:16 skrev Junio C Hamano:

Show 12 quoted lines

> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> 
> > måndag 09 februari 2009 07:04:46 skrev Junio C Hamano:
> >> What's troubling more is that this would seem to leave the result even
> >> more inconsistent if there are more than one packs that need to be
> >> replaced.
> >
> > Why? We don't prune the old objects if we fail. The result might be a lot
> > of redundancy, but nothing should be lost.
> 
> I was not talking about any loss.  The result would be a funny mixture of
> permutations of {old-,}pack-*.{pack,idx} the user needs to match up after

We don't leave old-files around unless we go very very wrong and only in that case would be leave "old"-files for one pack around and only if gc wants to replace a pack with the same name. That would not be fatal and the user can continue repacking to get rid of the redundant stuff once the cause of them problem is fixed.

For the simple case of "failure" I recover and return 0 (but don't prune the old packs), because no damage is done so I don't expect anyone to actually even try manual cleanup and why should they?

For the hard case, the user seek advice because I cannot image what would be the cause. Today even a simple and likely problem will cause a fatal corruption of the repo and that is my concern right now, not what happens when the disk fails in between the mv's.

Show 6 quoted lines

> figuring out what corresponds with what other one, and I think an expert
> who is asked for help would have hard time matching them up too, even
> though that is what you suggested in the message.
> 
> That troubled me and I was wondering if we can make the recovery simpler
> for the users.

-- robin