tisdag 10 februari 2009 16:59:16 skrev Junio C Hamano:
> Robin Rosenberg <robin.rosenberg@xxxxxxxxxx> 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.
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
