To: gnu-arch-users@gnu.org
Subject: Re: [Gnu-arch-users] Removing the last changeset(s) from the archive
References: <20041114111431.E15533@mofo.meme.com>
	<4197AAA5.7080501@panoramicfeedback.com>
	<20041114131601.O15533@mofo.meme.com>
From: Brian May <bam@snoopy.apana.org.au>
Mail-Followup-To: gnu-arch-users@gnu.org
Date: Mon, 15 Nov 2004 09:03:57 +1100
In-Reply-To: <20041114131601.O15533@mofo.meme.com> (Karl O. Pinc's message
	of "Sun, 14 Nov 2004 13:16:01 -0600")
Message-ID: <sa4hdns9jg2.fsf@snoopy.apana.org.au>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list
Sender: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Errors-To: gnu-arch-users-bounces+migo=homemail.com@gnu.org
Status: RO
Content-Length: 1741
Lines: 47
>>>>> "Karl" == Karl O Pinc <kop@meme.com> writes:

    Karl> On 2004.11.14 12:57 Aaron Bentley wrote:
    >> Karl O. Pinc wrote:
    >>> I'll fix the bug and commit the change, but do something
    >>> wrong and accidently include portions of my larger problem
    >>> in the commit.  It'd be nice to be able to 'do over'.
    >> How about tla replay --reverse $REVSIION; tla sync-tree $REVISION;
    >> tla commit -s "undid botched bugfix"?

    Karl> The bugfix was not botched, the archive is botched.  I want
    Karl> the tree I've got, I just want to make two commits instead of one.
    Karl> (Or make one partial commit now and others later.)

So make that 3 commits instead:

1 commit is the botched one.

1 commit reverses the botched one so that everything is exactly the way
it was before.

1 commit is the commit exactly the one you originally intended.

That way:
* you have complete history of everything (including mistake).
* you don't mess up other archives no matter how up-to-date they are.
* you still have 1 small patch for the bug fix.

While there might be circumstances where you have to physically delete
a changeset (e.g. if you accidently commit an excessively large or
private file to a public archive), I don't think this is one of them.

It could also be argued that you should always run "tla changes
--diffs" before "tla commit" to minimize the chance of a mistake
(although that doesn't help if you forget to include the filename in
"tla commit").
-- 
Brian May <bam@snoopy.apana.org.au>


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@gnu.org
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/