git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Robin Rosenberg <robin.rosenberg.lists@dewire.com>
Cc: git@vger.kernel.org, Johannes.Schindelin@gmx.de, spearce@spearce.org
Subject: Re: [PATCH] Make repack less likely to corrupt repository
Date: Tue, 10 Feb 2009 15:56:49 -0800	[thread overview]
Message-ID: <7vd4dpkfr2.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <200902110051.20975.robin.rosenberg.lists@dewire.com> (Robin Rosenberg's message of "Wed, 11 Feb 2009 00:51:20 +0100")

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

> tisdag 10 februari 2009 21:16:31 skrev Junio C Hamano:
>> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
>> 
>> >> 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. 
>> 
>> You can succeed for the first name and then fail for the second name, for
>> example, and can end up with old-pack-* and pack-* with the same name.  I
>> found that potentially confusing.  Since you are trying to improve the
>> area, it would be nicer to make it less prone to fail and easier to
>> recover.
>> 
>> Here is another attempt to rewrite it, which is closer to what you are
>> doing in your patch, but hopefully easier to understand what is going on
>> and more atomic.
>
> Almost perfect.
>
>> +# If renaming failed for any of them, roll the ones we have
>> +# already renamed back to their original names.
>> +if test -n "$failed"
>> +then
>> +	rollback_failure=
>> +	for file in $rollback
>> +	do
>> +		mv "$PACKDIR/old-$file" "$PACKDIR/$file" ||
>> +		rollback_failure="$rollback_failure $file"
>> +	done
>> +	if test -n "$rollback_failure"
>> +	then
>> +		echo >&2 "WARNING: Some packs in use have been renamed by"
>> +		echo >&2 "WARNING: prefixing old- to their name, in order to"
>> +		echo >&2 "WARNING: replace them with the new version of the"
>> +		echo >&2 "WARNING: file.  But the operation failed, and"
>> +		echo >&2 "WARNING: attempt to rename them back to their"
>> +		echo >&2 "WARNING: original names also failed."
>> +		echo >&2 "WARNING: Please rename them in $PACKDIR manually:"
>> +		for file in $rollback_failure
>> +		do
>> +			echo >&2 "WARNING:   old-$file -> $file"
>> +		done
>
> Exit 1 here.  We did not succeed in rolling back
>
>> +	fi
>> +	exit 1
>
> But here we should exit 0 because we succeeded in rolling back the changes,
> so we do not need to scare the user.

We failed to honor what the end user wanted: to repack.  Why should we
exit 0 here?

  reply	other threads:[~2009-02-10 23:58 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-09  0:44 [PATCH] Make repack less likely to corrupt repository Robin Rosenberg
2009-02-09  6:04 ` Junio C Hamano
2009-02-10  7:07   ` Robin Rosenberg
2009-02-10 15:59     ` Junio C Hamano
2009-02-10 16:57       ` Robin Rosenberg
2009-02-10 20:16         ` Junio C Hamano
2009-02-10 23:51           ` Robin Rosenberg
2009-02-10 23:56             ` Junio C Hamano [this message]
2009-02-11  0:27               ` Robin Rosenberg
2009-02-11  0:31                 ` Junio C Hamano
2009-02-11 17:08                   ` Robin Rosenberg
2009-02-15 16:15                   ` Robin Rosenberg
2009-02-15 16:46                     ` Johannes Schindelin
2009-02-15 18:42                       ` Robin Rosenberg
2009-02-15 20:09                         ` Junio C Hamano
2009-02-16  5:17                           ` Robin Rosenberg
2009-02-19 22:21                           ` Robin Rosenberg
2009-02-19 22:44                             ` Johannes Schindelin
2009-02-20  0:09                               ` Junio C Hamano
2009-02-20  0:09                               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vd4dpkfr2.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=robin.rosenberg.lists@dewire.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).