|
From: | Karl O. Pinc |
Subject: | Re: [Gnu-arch-users] Removing the last changeset(s) from the archive |
Date: | Sun, 14 Nov 2004 13:45:30 -0600 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |