gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl O. Pinc
Subject: Re: [Gnu-arch-users] Removing the last changeset(s) from the archive
Date: Sun, 14 Nov 2004 15:23:29 -0600


On 2004.11.14 14:25 John Meinel wrote:

I think you've just described the difference between a dev tree, and a stable tree.

But if you really want "this tree is always good", you probably want something more like a stable branch, rather than trying to do that with your dev branch.

When I'm developing I'm partly using revision control to keep track
of what I'm working on.  I just don't want it to get in the way,
so, especially while I'm learning arch I don't want to have to
stop and figure out how to undo a commit mistake.  But
that's niether here nor there because the'll always be
mistakes.  In terms of using revision control as a
brain extension, I'd like to be able to try things
out in my development branch with the freedom allowed
when I always know I can undo, so I want the commits
in the archive to be "clean" cuts of what I think I've
done.  As I often am doing more than one thing at a time
this means committing with care, to ensure that
'one thing' gets committed at a time.

Certainly
there's always a fixup when the rule is "archive
changes are permanent", but there's more brainwork
when recovering from a commit mistake, and more brain
work should one of my current ideas dead-end and
I have to make sense of what to revert.  (I'm not
talking here of un-committing a recent change
but of backing out something old and then commiting
that revert to the tree.)  A quick 'undo-commit'
after making a commit mistake would be handy,
but not essential.

Anybody sharing an archive would have to live
without 'undo-commit', given that arch has
no network protocol.  In some sense sharing
can be construed as the difference between a
stable and a deveopment branch.  Because many
will have to live without 'undo-commit' I wouldn't
think it worth doing unless it can be done easily and
cleanly.

Absent an undo-commit, a 'standardized' interface
for replay -reverse;sync-tree;commit would reduce the
"Oh no!" factor of making a commit mistake.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]