Re: [Gnu-arch-users] Removing the last changeset(s) from the archive

[Karl O. Pinc]

On 2004.11.14 13:13 Charles Duffy wrote:
> On Sun, 2004-11-14 at 13:19 -0600, Karl O. Pinc wrote:
> > 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"?
> >
> > So far, my solution is:
> >
> > tla commit -s 'Uh, commited more files that I should have. This
> revision
> > and the last one are broken.'
>
> You mean this?
> $ tla commit -s 'Reverse botched commit; next one has standalone
> bugfix'.

Maybe that's what I should mean.  In general I just go on and
finish fixing whatever I was working on (the larger problem)
and commit when I get that working and then the archive again
has a working revision.

Reverse/sync-tree/commit looks like it would be the right way to keep
the latest revision in the archive 'working' as often as possible.

That the moment my archive is not shared so I don't care whether the
latest revision works all the time or not.  My thoughts are that
it'd be nice to be able to keep an archive where _all_ the
revisions work, which leads me to want to 'un-commit'.  Although
it's not exactly true that I want the trees in the archive to
work.  It's more like I want them to be mental checkpoints.
Done with this part, check. Done with that, check.  Goofing
up a commit violates this mental model.

Karl <address@hidden>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein